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ABSTRACT 


This thesis is a part of a continuing effort to design 
and implement a diagnostic expert system for the MK92 MOD 2 
Fire Control System (FCS) undertaken by the Naval 
Postgraduate School (NPS) faculty and graduate students. 

The focus of this thesis is the development of a structured 
methodology for the design and implementation of an expert 
system in an expert system shell utilizing a visual 
programming language« Guidelines for the application of the 
structured methodology in the Adept expert system shell were 
developed and applied to the initial Performance module of 
the MK92 MOD 2 FCS Maintenance Advisor Expert System 
prototype developed in an earlier effort. 
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I. 


INTRODUCTION 


A. BACKGROUND 

This thesis is a part of the continuing effort to design 
and implement a diagnostic expert system for the MK92 MOD 2 
Fire Control System (FCS) undertaken by the Naval 
Postgraduate School (NPS) faculty and graduate students. 

The MK92 MOD 2 FCS is a complex weapons system based on 
1970's technology. Due to the age and complexity of this 
system, the job of maintaining and repairing the system has 
been an overwhelming task for the enlisted fire control 
technician. Often, they are unable to correctly diagnose 
system failures which results in increased system downtime 
and therefore a reduction of the ship's operational 
readiness and war fighting capability. In order to remedy 
this situation, costly outside technical assistance is 
frequently required to repair tte system. 

As manpower levels decrease in the Navy, due to current 
downsizing trends, the number of senior, experienced 
technicians decreases as well. This situation complicates 
matters further and increases the requirement for outside 
technical assistance. In an effort to reduce costs, system 
downtime and improve the shipboard technician's ability to 
better determine, diagnose and resolve problems occurring in 
the system, the Naval Surface Warfare Center (NSWC), Port 
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Heuneme Division (PHD) enlisted the help of the Naval 
Postgraduate School to develop a prototype expert system for 
the MK92 MOD 2 PCS. 

B. OBJECTIVES 

The primary objective of this thesis is to develop a 
structured design and programming methodology for expert 
system shells utilizing a visual programming language. The 
secondary goal is to improve upon the initial Performance 
module prototype, developed in an earlier effort, through 
the application of this new structured design and 
programming methodology. 

C. RESEARCH QUESTIONS 

This research endeavors to answer the following 
questions: 

• Can a structured methodology be developed for expert 
system shells utilizing a visual programming 
language? 

• Can guidelines be developed for the Adept expert 
system shell utilizing the new structured methodology? 

• How can the application of such a structured 
methodology improve the Performance module prototype? 

D. SCOPE AND ASSUMPTIONS 

This thesis focuses on the development of a structured 
methodology to be applied to system development in expert 
system shells utilizing a visual programming language. It 
is assumed that the reader has a basic knowledge and 
understanding of the predominate structured design and 
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programming methodologies, the Systems Development Life 
Cycle (SDLC), expert systems and traditional text-based 
programming languages. The scope of the application of the 
developed methodology is limited to the Adept expert system 
shell, but provides useful insight for its application to 
fourth generation languages (4GL) and other visual 
programming environments. 

E. METHODOLOGY 

The methodology used in this thesis consisted of three 
distinct stages. In the first stage, a thorough review of 
structured design and programming methodologies was 
undertaken. In the second stage, guidelines for the 
application of the structured methodology in the Adept 
expert system shell were developed. Finally, the third 
stage applied those guidelines to the initial Performance 
module prototype. 

F. THESIS ORGANIZATION 

This thesis consists of six chapters and one appendix. 

Chapter II provides background material on the MK92 MOD 
2 Fire Control System (FCS), the history of the MK92 MAES, 
the elements of the MK92 Daily System Operability Test 
(DSOT), and the development process of the initial 
Performance module prototype. 
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Chapter III reviews the principles of structured design 
and programming in traditional Computer Based Information 
Systems (CBIS). 

Chapter IV provides an overview of the basic constructs 
of the Softsell Adept visual programming expert system 
shell. 

Chapter V provides guidelines for the application of 
traditional structured methodologies, reviewed in chapter 
three, to the Adept expert system shell. In addition, these 
guidelines are applied to the initial Performance module 
prototype. 

Chapter VI discusses the lessons learned and insights 
gained during the development of this thesis. 

Appendix A contains a structure chart of the Performance 
module prototype upon application of the new structured 
methodology. 
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II. MK92 MAINTENANCE ADVISOR EXPERT SYSTEM BACKGROUND 


This chapter discusses the MK92 Fire Control System 
(FCS), the history of the MK92 Maintenance Advisor Expert 
System (MAES), the elements of the MK92 Daily System 
Operability Test (DSOT), and the development process of the 
initial Performance module prototype of the MK92 MAES. 

A. MK92 MOD 2 FIRE CONTROL SYSTEM 

The MK92 MOD 2 FCS can be found on the United States 
Navy Oliver Hazard Perry class Guided Missile Frigates (FFG 
7), as well as Patrol Hydrofoil Missile class (PHM) ships, 
U.S. Coast Guard High and Medium Endurance Cutters, and the 
Australian Anzac and FFG 7 class ships. 

The MK92 MOD 2 FCS, illustrated in Figure 2.1, is a high 
performance, multi-purpose complex weapons system. It is 
part of an integrated, modular system that contains 
search/track radar, a digital computer, servo system, 
hydraulic system, amplidynes and other sophisticated 
electronic components. The function of the system is to use 
radars, guns and missiles in order to: 

1. Locate and track air, surface and shore targets. 

2. Calculate the targets future positions relative 
to the ship's current position. 

3. Use the above information to train and launce 
the gun and missiles that will destroy the 
designated targets when required. 
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A more thorough description of the system can be found in 
Smith (1993) and Lewis (1993). 

B. MK92 MOD 2 MAINTENANCE ADVISOR EXPERT SYSTEM HISTORY 

Because of the complexity of the MK92 MOD 2, the job of 
maintaining and repairing the system has been an 
overwhelming task for the enlisted fire control (FC) 
technician, primarily due to a lack of knowledge, 
experience, and limited technical manuals. Although FC 
technicians receive intensive training from Naval Training 
Centers (NTC), textbooks and classroom lectures can not 
equip technicians properly with the required knowledge to 
isolate many casualties in such a complex weapons system. 

The lack of experience and technical knowledge of the 
system led to increased equipment downtime and therefore, a 
reduction of the ship's operational readiness and war 
fighting capability. In order to remedy this situation, 
costly outside technical assistance is frequently required 
to repair the system. This assistance comes from the Naval 
Sea Systems Command (NAVSEA) where the expert knowledge 
resides in the experienced civilian technical engineering 
representative. 

In an effort to reduce costs, system downtime and 
improve the shipboard technician's ability to better 
determine, diagnose, and resolve problems occurring in the 
system, the Port Hueneme Division (PHD) of the Naval Surface 
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Warfare Center (NSWC) initiated, in 1992, the development of 
a prototype diagnostic expert system. The goal of the 
development effort was to collect the combined knowledge of 
the preeminent MK92 MOD 2 expert engineers and represent it 
in the form of an expert system software program. This 
program could then be deployed aboard ships for use by FC 
technicians. Unfortunately, PHD, NSWC personnel ran into 
difficulties developing the software during the initial 
program development. It was at this point that PHD 
requested the assistance of the Naval Postgraduate School 
(NPS) in the software development of the prototype. 

The domain for the MK92 FCS MAES is the MK92 Daily 
Systems Operability Tests (DSOT), described in detail in the 
following section. The areas of the DSOT knowledge base 
that were originally chosen for inclusion in the initial 
prototype effort were as follows: 

• CAS/STIR DSOT Performance Tests 
DSOT Calibration Tests 
CAS/STIR Transmitter RF Power Checks 
However, at this time, only expert knowledge for the 
Calibration and Performance areas of the DSOT have been 
acquired and implemented into the MK92 FCS MAES. Knowledge 
to develop the Transmitter RF Power Checks prototype is 
currently being acquired for later implementation into the 
prototype in fiscal year 1995. 
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Although the primary focus of this thesis is the 
Performance module of the MAES, a brief chronology of events 
of the project, since NPS involvement, is required in order 
to provide the reader with an understanding of the 
proverbial "big picture" and, of course, for completeness. 
The events are as follows: 

1. In 1993, a cost/benefit analysis was conducted by 
Steven H. Powell (1993) that determined that the 
development and implementation of a MAES for the MK92 
MOD 2 would result in considerable savings to the Navy. 


2. In 1993, Claude D. Smith (1993) and Clinton D. Lewis 
(1993) developed the initial prototype for the 
Performance module of the MAES. 

3. In September 1993, the first prototype of the 
Performance Module was given to PHD for initial testing 
and evaluation. 

4. In January 1994, the author took over the 
responsibility of the refinement of and 
development/application of a structured design 
methodology to the Performance Module. 

5. During 1993/1994, David M. Geick and Steven E. 

Mikler (1994) developed the initial prototype for the 
Calibration module of the MAES. 

6. During 1993/1994, Susan Tally (1994) had begun the 
process of developing an integrated parts database 
system for the MAES, Continuing development of the 
database is currently being pursued by Janie N. Crawford 
(1994) . 

7. In late 1993, John L. McGaha (1994) was assigned the 
responsibility of maintenance and configuration 
mangagement of the Calibration module as well as 
developing implementation procedures for the system. 

8. In March 1994, verification, validation and testing 
of the Calibration module was being conducted by Kent R. 
Dills and Timothy F. Tutt (1994). 
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C. THE MK92 DAILY SYSTEM OPERABILITY TEST 

The DSOT is a part of the daily maintenance procedures 
and a sub-system of the MK92 MOD 2 PCS. It is a 
computerized system that provides a quick, yet 
comprehensive, assessment of the operational readiness of 
the system. The DSOT includes injecting simulated targets 
into the radars in order to determine if all systems are 
functional, and checking the validity of system responses to 
preprogrammed input target parameters. Upon completion of 
the system check, a printout is provided that lists NoGo and 
out-of-tolerance conditions, if any, for twenty different 
areas in the system. The two specific sections that the 
DSOT covers are Performance and Calibration of the MK92 PCS. 
Por the purpose of this thesis, the focus will be on the 
Performance aspect of the system. Por a more technical and 
detailed description of the DSOT refer to the thesis' by 
Smith (1993) and Lewis (1993). 

D. PROTOTYPE DEVELOPMENT OF THE PERFORMANCE MODULE 

Although the development of the Performance module 
prototype is covered in detail by Smith (1993) and Lewis 
(1993), a brief overview is provided here for easy 
reference. 

1. Knowledge Acquisition/Representation 

Since the MAES project was initiated at PHD, NSWC, it 
was not necessary for the NPS project team to select the 
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domain experts. The primary expert assigned to the project 
was, and still is, Mr. Dorin Sauerbier of Paramax. Due to 
his extensive experience with the MK92 MOD 2 PCS, he has 
proven to be an invaluable source of information. The 
knowledge provided by Mr. Sauerbier is a combination of 
heuristics from his own experience and that of other experts 
as well as information provided by the MK92 MOD 2 PCS 
technical manuals. 

The representation of the knowledge, acquired by Mr. 
Sauerbier, was in the form of handwritten diagnostic trees. 
As troubleshooting expertise is usually hierarchical in 
nature, diagnostic trees were the most logical and suitable 
representation. Pigure 2.2 is an actual sample of a 
diagnostic tree provided by the domain expert. This 
particular tree represents a sub-division within the PC2 
Acquisition module of the system. Note from the figure that 
the methodology, used by the domain experts, in diagnosing a 
system failure is done in a series of yes/no steps. There 
are some areas in the system where there are nodes that have 
more than two possible decision choices; however, the nodes 
that have only yes/no choices generally prevail throughout 
the system. 
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2. Hardware/Software Selection 

Softsell Adept was chosen for the MAES. The 
choice of software packages was based upon the following 
criteria: 

• It is a procedural based software that was 
specifically designed for diagnostic expert 
system development. This matched the MAES 
knowledge representation. 

It provides a visual programming environment that 
produces a system that is easy to develop, 
maintain, and evolve. 

It is a Windows based program that integrates a 
graphic user interface with and expert system 
shell and, therefore, eliminates the need for two 
separate software packages. 

It was used successfully by the Army in the 
implementation of an Ml tank diagnostic system. 

Given the chosen software and the estimated size of 
the system, a 486 PC was selected as the developmental 
hardware platform. A final decision has not been made as to 
what hardware will be used for deployment; however, the 
choices are confined to either a 486 desktop PC or a 486 
laptop/notebook computer. 

3. Knowledge Implementation 

Knowledge implementation, as defined by Prerau 
(1990, p. 17), "....is the process of taking the knowledge 
found during knowledge acquisition and translating it into 
an operational expert system program by employing the 
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structures and paradigms that comprise the knowledge 
representation". 

Adept is a procedure-based expert system shell 
which utilizes a visual programming language that builds 
applications (programs) as a collection of procedures (sub- 
programs or modules). During initial prototype development, 
it became apparent that the knowledge document could be 
broken down into a series of modules which represented the 
procedures that a domain expert would follow in the 
diagnosis of system faults within the major areas and their 
associated sub-areas of the DSOT. Each module was then 
implemented as a procedure within Adept. Figure 2.3 is the 
Adept implementation of the FC2 Acquisition diagnostic tree 
presented in Figure 2.2. A comparison of Figure 2.2 and 
Figure 2.3, reveals that the Adept representation is almost 
identical to the knowledge document from which is was 
constructed. It becomes apparent why the Adept software was 
selected as the implementation software. 

Appendix A of Smith's (1993) and Lewis' (1993) thesis' 
contain the descriptions and diagrams of the procedures in 
the application of the initial Performance module prototype. 

Chapter III reviews the principals of structured design 
and programming in traditional Computer Based Information 
Systems (CBIS). 
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Figure 2.3: FC2 ACQ Ba Procedure 
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III. STRUCTURED METHODOLOGIES OVERVIEW 


This chapter discusses the characteristics of structured 
design and programming of traditional text-based programming 
languages in view of applying them to the development of 
systems utilizing an expert system shell that employs a 
visual programming language. Specifically, it addresses 
structured design and programming, structure charts, 
modularization, inter-modular and intra-modular design 
characteristics, and other miscellaneous design 
characteristics. 

A. STRUCTURED METHODOLOGIES 

Structured is defined, by the Mirriam-Webster 
Dictionary, as either "something that is made up of 
interdependent parts in a definite pattern of organization 
or as an arrangement or relationship of elements in a 
substance, body or system". Methodology is defined by Aktas 
(1987, p.33) as "A body of methods, rules, and postulates 
employed by a discipline". According to both Aktas (1987) 
and Page-Jones (1988), by applying a specific set of 
methods, rules and postulates to a problem, one will be able 
to design a structured, well-defined, maintainable, 
flexible, and standardized computer based information system 
(CBT:3) . 
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structured methodologies are used to implement and/or 
supplement the systems development life cycle (SDLC). 
According to Whitten et al (1989, pp. 108-129), the 
predominant structured methodologies used today are: 


• Structured Analysis is a technique for system 
specification that models the flow of data in a new 
or existing system using a series of flow models. 
This method compliments/supports the survey, study, 
definition and selection phases of the SDLC. 

Structured Design is the process of factoring a 
system into a top-down hierarchy of independent 
modules. The tool used here is the structure chart. 
This methodology supports the program design portion 
of the design phase in the SDLC. 

• Structured Progrananing is a set of rules by which a 
programmer designs the logic and code within 
modules. This supports the construction, delivery, 
and maintenance/improvement phases of the SDLC. 


To date, most of the various structured methodologies 
that have been developed have focused predominately on the 
design of the more common types of text-based CBIS. 
Primarily, these include Transaction Processing Systems 
(TPS), Management Information Systems (MIS), and Decision 
Support Systems (DSS). Currently, there are little to no 
published approaches pertaining to a structured methodology 
for use in the development of expert systems, or for that 
matter any application system, using a visual programming 
language. 
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In order to develop such a methodology, we must first 
understand the characteristics of the methodologies that 
have been established for the text-based CBIS and then apply 
those characteristics, where feasible, to expert systems 
development tools employing visual programming. The purpose 
of this chapter is to provide the reader with an overview of 
current CBIS structured methodology characteristics as they 
apply specifically to design and programming. However, only 
those characteristics of CBIS structured methodologies that 
can be applied to visual programming will be emphasized, 
since a detailed discussion of all the characteristics of 
structured methodologies would detract more than it would 
contribute to the purpose of this thesis. 

B. STRUCTURED DESIGN VS STRUCTURED PROGRAMMING 

Previously, when structured design and structured 
programming methodologies were developed (and were typically 
applied to second and third generation languages) there was 
a rather clear delineation of the roles and responsibilities 
of each methodology. However, since the advent of higher 
level languages, such as expert system shells using visual 
programming, the line of demarcation between the two 
methodologies has blurred. This is especially true in 
Adept. Primarily, this is because expert systems utilizing 
visual programming place an additional layer or interface 
between the programmer and the traditional style of coding. 
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In visual programming, many of the traditional programming 
structures are implicit and lie beneath the visual objects 
of the interface. Without the actual coding, many of the 
standard characteristics of structured programming either 
fade away completely or overlap into structured design. 

The constructs of Adept's visual programming language 
will be discussed in greater detail in the next chapter. 

The following sections provide a clearer differentiation of 
the roles of structured programming and structured design. 

1. Structured Desigrn 

The concept of the structured design methodology is 
to factor computer programs into a top-down hierarchy of 
independent modules (Whitten et al, 1989, p. 115). These 
modules consist of a series of instructions that, if 
developed properly, serve only one solitary function (this 
property is known as cohesion ). Equally as important is the 
ability of a module to perform its function independent of 
other modules (this property is known as coupling ). 
Structured design supports the program design phase of the 
SDLC as well as simplifying both the construction and 
delivery phases via its top-down structure (Whitten et al, 
1989, p.ll5). 

2. Structured Programming 

Structured programming is a "process-oriented 
technique for designing and writing programs with greater 
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clarity and consistency" (Whitten et al, 1994, p. 145). 

This technique deals primarily with the logic and code of a 
program and was originally developed for traditional text- 
based programming languages. Research has shown that a well 
structured program can be written using only three control 
structures. These three control structures, referred to as 
restricted control structures (Whitten et al, 1989, p. 113), 
are: 

• a sequence of instructions or group of instructions 

• a selection of instructions or group of instructions 
based on some decision criteria (this construct is often 
referred to as the if-then-else or case construct) 

• an iteration of instructions or group of instructions 
based on some criteria (this construct comes in two 
basis forms: repeat-until and do-while) 

These constructs can be used alone or together in any 
series of combinations. However, there are two main 
characteristics of employing these constructs. First, each 
structure must exhibit a single-entry, single-exit property 
(Whitten et al, 1989, p. 113). In other words, there can 
only be one point of entry into and one point of exit out of 
each structure. Second, the program code must be able to be 
read page by page and from top to bottom with no backward 
references. Some programmers have incorrectly interpreted 
this last characteristic to mean that the program code, 
where applicable, should not include the use of GOTO 
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statements. Structured programming does not seek to 
eliminate the use of GOTO statements; rather it endeavors to 
reduce the undisciplined application of backward 
referencing. 

C. STRUCTURE CHARTS 

Structure charts, also known as structure diagrams, are 
structured design tools used by system designers to 
represent the shape, size and configuration of a system 
(Aktas, 1987, pp. 78-80; Page-Jones, 1988, pp. 33-35; 

Whitten et al, 1989, pp. 115-117). Structure charts are 
also used to assist in breaking or partitioning a system 
down into a top-down hierarchy of modules and sub-modules. 
For example. Figure 3.1 is a partial structure chart of the 
functions of an Automatic Teller Machine (ATM). Each module 
represents a specific function that a typical ATM performs. 
Those functions at the top level of the structure chart 
represent the main functions. The modules located at the 
second level represent the subfunctions that must be 
performed in order for the system to accomplish its primary 
functions on the first level. As we progress down to the 
lower levels of the structure chart, the functions of the 
individual modules become more specific and simplified. 

D. MODULES 

A module is a series of instructions or program 
statements that are grouped together to perform one solitary 
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function. Modules have four basic attributes; input and 
output flows to other modules, function, mechanics, and 
internal data (Page-Jones, 1988, p. 35). These are defined 
as follows: 

• Inputs and outputs refer to the parameters received 
from and returned to other invoking modules. 

• The function refers to how the module manipulates the 
input data in order to produce the output data. 

• Mechanics refers to the actual coding within the 
module which is required in order for the module to 
perform its designated function. 

• Internal data refers to the data workspace of a module 
to which only that module has access. 

A module may perform its designated function alone or it may 

call upon other modules to assist it in the performance of 

its assigned task. In Figure 3.1, four modules are called 

upon to perform specific tasks for the Checking module. On 

the other hand, the modules at the lowest level of the chart 

do not require other modules to perform their functions. 

A module is primarily conceived of in the structured 
design process. However, it is not developed and tested 
until the structured programming techniques have been 
applied to it. The following sections present guidelines 
for good module design. 

1. Black Boxes 

All modules within the system should be created as 
if it were a black box. A module is considered a black box 
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when the function of the module is known and has a well- 
defined role, but the details as to how the module performs 
the function is unknown. Black boxes are used in order to 
reduce a large, complex system into small, useable parts. 

The use of black boxes serves to make the system easier to 
design, test, maintain, and understand. They are used in 
structure charts because the details of the function of each 
module would only serve to confuse at that point in the 
design process. 

2. Factoring 

Factoring is a decomposition method that is used to 
separate a specific function from one module into a sub- 
module of its own (Aktas, 1987, p.l25). For example, 
referring to Figure 3.1, the module marked Savings (Parent), 
under the Deposit Funds module, has four sub-modules 
(children) that each perform a specific function. 

Logically, however, when used in conjunction with one 
another, they contribute to the performance of the parent 
module's function. Factoring simplifies the system by 
promoting reuse and reducing individual module size. Module 
size will be addressed in Section C of this chapter as one 
of the intra-modular characteristic. Module reuse is 
attained by factoring out an activity that is duplicated in 
several modules. In the ATM example, the function of 
obtaining a specified dollar amount from the customer was 
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utilJ.zed as a sub-function by more than one of the primary 
functions of the overall system. Therefore, this function 
was factored out into a module of its own and called Get 
Dollar Amount. The reason for factoring this module is to 
reduce redundant code, thereby promoting module reuse and 
simplifying the system. 

E. INTRA-MODULAR DESIGN CHARACTERISTICS 

Intra-modular design characteristics refer to 
characteristics within a module. 'When a systems designer 
partitions a system into a series of modules, he/she must 
ensure that the design of the individual modules are 
functionally cohesive. The designer must be concerned with 
the module's function, cohesion and size. Intra-modular 
design characteristics originate as characteristics of the 
structured design methodology; however, they can not be 
fully applied and tested until they are used as part of a 
structured programming methodology. 

1. Cohesion 

Cohesion refers to the measure of the degree to 
which a module performs a solitary, well-defined, problem- 
related and understood function (Aktas, 1987, p. 122). The 

following is a brief definition of each type of cohesion 
from the easiest to the hardest to maintain. 
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a. Functional Cohesion 


A module has achieved functional cohesion if it 
performs one solitary, well-defined and understood function. 

Jb. Sequential Cohesion 

A module is sequentially cohesive if the 
instructions/activities within that module must be performed 
in a specific, sequential pattern in order for the module to 
perform its function correctly. In other words, the 
instructions/activities within that module follow a specific 
order because the output data from one instruction/activity 
serves as required input data for the next 
instruction/activity. 

c. Communicational Cohesion 

A module is communicationally cohesive if the 
activities within the module use the same input or output 
data. 

d. Procedural Cohesion 

In a procedurally cohesive module, the 
instructions may be totally unrelated. However, control 
passes from one activity to another rather than data. 

Unlike sequential cohesion, the instructions/activities in a 
procedurally cohesive module are not dependent on each other 
for completion of their individual functions. 
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e. Tewporal Cohesion 

Temporal cohesion is similar to procedural 
cohesion in that the instructions/activities are unrelated 
to one another. However, within a tengsorally cohesive 
module, the instructions/activities are grouped together 
because they are all performed at the same time. 

f. Logical Cohesion 

A module is logically cohesive if the activities 
of the module are grouped together solely because their 
functions contribute to a general category of activities and 
the selection of a specific activity is chosen from outside 
the module. For example, let's suppose that a module, 
called Initialization, includes the following activities: 

• Initialize printer 

• Initialize variable_A 

• Initialize variable_X 

• Initialize device_A 

These activities are grouped together, not because they 
contribute to one solitary function, but rather because each 
individual activity within the module performs a similar 
function on different objects. In addition, each time the 
module is used, not all the functions are performed. 

Instead, the choice of which activity to perform is selected 
by another module and that choice is passed as a parameter 
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into this module. In this case, the module is logically 
cohesive. 

g. Coincidental Cohesion 

A module is considered to be coincidentally 
cohesive if the instructions/activities within that module 
are totally unrelated to one another. 

A more indepth analysis and description of the 
various types of cohesion can be found in Page-Jones (1988, 
pp. 84-96) . 

2. Module Size 

In structured programming, the smaller the module's 
size the easier it is to implement, maintain and reuse. As 
stated previously, the optimum cohesion characteristic for a 
module is functional cohesion. If the module performs one 
well-defined, solitary function, then it is as small as it 
can get without loosing cohesion. However, there are trade¬ 
offs to achieving functional cohesion. One primary trade¬ 
off is programmer comprehension. According to Page-Jones 
(1988, p. 104) "our ability to understand a module and to 
find bugs in it depends upon our being able to comprehend 
the whole module at once". Following that line of thinking, 
a module that fits on one page and is visible to the 
programmer in full, is easier to comprehend and debug than a 
module that is two or more pages. Therefore, a module that 
achieves functional cohesion and consists of two pages of 
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code may actually be harder to comprehend and debug than a 
module that is only sequentially cohesive and consists of 
only one page of code. 

The determination as to which takes precedence, module 
cohesion or programmer comprehension, is dependent upon the 
system itself and system designer preference. 

F. INTER-MODULAR DESIGN CHARACTERISTICS 

Inter-modular design refers to those characteristics 
that are exhibited between modules. Similar to the intra- 
modular design, these characteristics also initially emerge 
and are applied as part of structured design but are not 
fully implemented and/or tested until they are applied as 
part of structured programming. 

Concerns of a system designer when partitioning the 
system and designing modules is how the modules interact 
with each other. Of primary concern to the system designer 
is coupling. 

1. Coupling 

Coupling is defined as the degree of interdependence 
between two or more modules in the system (Page-Jones, 1988, 
p. 58). The lower the degree of coupling, the better the 
overall system. In order to reduce coupling between 
modules, a system designer must create connections that are 
narrow, direct, local, obvious and flexible (Page-Jones, 
1988, p. 60). The following list provides definitions of 
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the various type of coupling from the best to the worst to 
maintain. 

a. Data Coupling 

Two modules are data coupled if they communicate 
through the parameters of the modules and the pieces of data 
are simple and uncomplicated. 

Jb. Stcurp Coupling 

Stamp coupling is said to exist when the 
information being passed between two modules represent a 
group of related data items that are essential to the 
modules. 

C- Control Coupling 

Control coupling occurs when information is 
passed from one module to another whose sole purpose is to 
control the internal logic of the receiving module. 

d. Common Coupling 

Common coupling occurs when the data passed 
between modules is contained in an area that is accessible 
to other modules. Another name for common coupling is 
global coupling (Page-Jones, 1988, p.73) 

e. Content Coupling 

Content coupling occurs if one module accesses 
or refers to the inside of another module. In this case, 
one module is required to know the inner workings of another 
module. This defeats the concept of the black box. 
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A more indepth and detailed analysis of coupling and its 
characteristics can be found in Page-Jones (1988, pp. 58-79) 
G. OTHER GOOD DESIGN/PROGRAMMING CHARACTERISTICS 

Although the characteristics, stated previously, play 
the primary role in the overall quality of systems design, 
they can not be considered alone. Other characteristics, 
listed below, play an important role in systems design as 
well. The following characteristics are predominately 
structured design techniques. However, the first 
characteristic, restrictivity/generality, is also applied 
during structured programming. 

1. Restrictivity/Generality 

In good design practices, a system designer does not 
want to make individual modules too restrictive or too 
general (Page-Jones,1988, pp. 133-134). A module is too 
restrictive if it performs a function that is so specific 
and narrow that it does not promote reusability. A module 
is too general if it performs a function that is so broad 
that much of the code is rarely used. That type of coding 
serves only to complicate and clutter the system. 

2. Fan-out 

Fan-out refers to the maximum number of children 
modules that any given parent module can have and still 
maintain system clarity. The recommended upper limit of 
fan-out modules has typically been approximately seven. 


31 


Page-Jones (1988, pp. 139-140) states that the reason for 
the number seven is based in human psychology. The optimum 
number of tasks that a given individual can handle, with 
little to no errors, is seven. The number of errors begins 
to increase exponentially as the number of tasks increases 
beyond seven. This theory has since been transposed to the 
design of CBISs. Although not a hard and fast rule, if a 
parent module has more than seven children, the system 
designer should re-evaluate the modules and determine if an 
intermediate level should be added. 

3. Fan-in 

Fan-in refers to the number of parent modules that 
any given child module can have and still maintain system 
clarity. In so far as module cohesion and interfaces are 
not sacrificed, the higher the fan-in, the better. 

Generally, the greater the amount of fan-in, the more reuse 
is promoted, which in turn promotes increased programmer 
comprehension and system simplicity. 

The traditional structured methodologies presented in 
this chapter will be adapted to expert systems utilizing 
visual programming languages and applied to the Performance 
module of the MK92 MOD 2 FCS MAES in Chapter V. However, in 
order for the reader to comprehend and evaluate the 
application of the structured methodology, an overview of 
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the fundamental constructs of the Adept expert system shell 
will be presented in the next chapter. 
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IV. ADEPT CONSTRUCTS 


This chapter provides an overview of the basic 
constructs of Softsell Adept visual prograinining as provided 
in the Adept Reference Manual (Himes et al, 1991). It 
introduces such constructs as applications, procedures, 
nodes, statements, variables, constants, operators, 
functions and objects. In addition, where appropriate, the 
Adept visual programming constructs will be briefly compared 
to traditional programming languages and expert system 
constructs. For a detailed description of the nuances of 
the Adept constructs or the techniques used in applying 
them, the reader is referred to the Adept Reference Manual. 
A. PROCEDURE-BASED PROGRAMMING 

Adept utilizes a creative approach to expert system 
development by combining visual application programming with 
expert systems. It is a procedure-based expert system shell 
that permits the programmer to build expert systems by 
creating and manipulating objects on a screen. 

Prior to the advent of visual programming, most expert 
system shells utilized a rule-based style of programming. 
Rule-based programming is generally represented as a series 
of IF/THEN or Condition/Action statements which include 
logical operators such as AND/OR. For example, consider the 
following two simple rules: 
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IF lightswitch is on 
AND lightbulb is on 
THEN lightbulb is good 

IF lightswitch is on 
AND lightbulb is off 
THEN lightbulb is defective 

The first rule concludes that the lightbulb is good if the 
lightswitch is in the on position and the lightbulb is lit. 
The second rule concludes that the lightbulb is defective if 
the lightswitch is in the on position and the lightbulb is 
not lit. Rule-based programming is easy to understand 
because it imitates the way in which humans tend to view the 
relationship between cause and effect (Himes et al, 1991, p. 
8). However, expert systems can also be tedious to develop 
if they contain a large number of rules. As is typical of 
text-based programming, they can be difficult to debug, 
maintain and evolve. 

Procedure-based programming is a new paradigm, developed 
at Stanford University, that uses graphical representations 
of procedures to create expert systems (Himes et al, 1991, 
p. 9). It was specifically designed in order to "make it 
easy to model business and technical procedures and then 
turn those procedures into interactive software 
applications" on personal computers (Himes et al, 1991, p. 
6). Figure 4.1 is an example of how the rule-based example, 
provided above, would be represented in a procedure-based 
programming language. This type of programming alleviates 
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Figure 4,1; Lightbulb Procedure 
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the developer of an expert system from having to be or 
become a professional text-based programmer. 

The following sections present the main constructs of 
visual procedural-based programming as implemented in Adept. 

B. APPLICATIONS 

An application usually consists of several procedures, 
where each procedure is made up of nodes, displays, 
variables, and functions. If Adept were to be compared to 
the ADA programming language, applications would equate to 
the overall program or system. The current version of the 
MK92 MOD 2 PCS MAES represents one ADEPT application 
consisting of approximately 250 procedures. 

C. PROCEDURES 

Similar to the third generation programming languages, 
such as PASCAL or ADA, where a system consists of a series 
of modules that call each other when required, an Adept 
application consists of a series of programs called 
procedures. A procedure consists of a series of visual 
objects called nodes. Analogous to the parent/child modular 
relationships in structured programming,, procedures can also 
be classified as either a parent or a child procedure or 
both. 

D. NODES/ARCS 

A node is a graphical object which represents a specific 
step or series of steps within any given procedure. It is a 
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visual object that allows end users to design and implement 
an expert system without having to deal with traditional 
text-based programming code. Actual programming code lies 
underneath each node and is transparent to the 
programmer/user, Since Adept is naturally a hierarchical 
programming language, nodes can be either a parent node, a 
child node or both. 

The flow of control is determined by evaluating each 
node in an Adept procedure. This evaluation returns one of 
three possible values: true, false or unknown. The value 
returned depends on the style and type of each node. 
Generally, a value is returned as a result of: 

User input 

Statement evaluation 

Evaluation of one or more child procedures 
Nodes are connected to other nodes via Arcs (refer to 
Figure 4.1). The purpose of an arc is to establish a 

link between nodes and indicate the seguence of 
program flows. There are three types of Arcs in Adept that 
correspond to the three values that a node can evaluate to: 
true, false and unknown. As nodes are evaluated, control is 
passed from a parent node to a child node via an arc. If 
the node is evaluated as true then control passes to the 
child node that is connected to the parent node by a true 
arc. Similarly, if a node is evaluated as false or unknown 
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then control is passed to the node connected by a false or 
unknown arc, respectively. 

In Adept, the task performed by any given node is 
dependent upon the style and type of node that is used by 
the programmer. 

1. Node Styles 

The style of a node determines the function that a 
node serves in a procedure. There are four basic styles in 
Adept and a custom style that is defined by the programmer. 
Each style can be identified by the symbol within the node. 
Figure 4.2 illustrates each of the basic node styles. The 
following is a brief description of each of the node styles, 
a. Calculation Node 

The functions of a calculation style node is to 
perform mathematical calculations, compare variables or to 
call a predefined function in Adept. This style of node is 
evaluated by executing the statement(s) attached to it and 
then returning a true, false or unknown value. 
b. Display Node 

Whenever it is necessary to convey information 
to or obtain information from a user, a display node must be 
used. This node has a display screen attached to it that 
can be customized to the program requirements. The 
evaluation of this style of node is based on the user's 
input. When the node is executed, the associated display is 
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presented to the user and he/she is asked to provide input 
to the program. Depending on the response, the node 
evaluates to true, false or unknown, and an appropriate arc 
path is followed. 

c. Result Node 

Adept utilizes a result node, which is a one-way 
link between two or more procedures, to perform the forward 
chaining aspect of the expert system shell. Forward 
chaining uses an available set of known facts in order to 
determine which procedure(s) will be triggered. The 
procedures that are triggered will in turn derive more facts 
about the situation and add those to the working memory of 
the program. This process continues until all facts that 
can be derived from the initial set of data have been found. 

In Adept, when a procedure, or a path within a 
procedure, has reached a conclusion, a result-style end node 
is used to transfer control to one or more children 
procedures who have the matching result-style start nodes. 
The child procedure(s) is executed only after Adept has 
evaluated the parent procedure. 

It is very easy for a traditional text-based 
programmer, using Adept for the first time, to confuse the 
function of a result node with that of the GOTO statement 
used in traditional programming languages. As such, he/she 
may attempt to apply traditional structured programming 
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methodologies for GOTO statements to result nodes. If a 
programmer were to limit the use of result nodes in the same 
manner in which GOTO statements are restricted in structured 
programming methodologies, it would limit the functionality 
of the forward chaining properties of the Adept expert 
system shell. It could also negatively impact the 
functionality and logic of the application. 
d. Goal Node 

A goal node is used when it is necessary to call 
upon one or more child procedures to solve a problem and 
return a value of true, false or unknown to the parent 
procedure. 

In expert system terminology, a goal node is how 
Adept performs backward chaining. Backward chaining starts 
with a premise and then looks for a procedure to prove it. 
The search for the premise continues until all procedures 
that might prove or disprove the premise have been searched. 

Similar to Call statements in traditional text- 
based programming languages, goal nodes allow Adept to 
create a two-way link between two or more procedures. When 
a goal node is reached, processing of the parent procedure 
ceases and a system call goes out to one or more child 
procedures that will solve a problem and return a value to 
the parent procedure. The calling goal node will then be 
evaluated, using the value returned from the child 
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procedure. Processing of the parent procedure will 
continue. 

e. Custom Nodes 

Occasionally, there is a requirement that can 
not be supported by the basic node styles. In this event, 
Adept allows the programmer to design his/her own customized 
node. This is accomplished by attaching a script to the 
custom node that specifies how a node is to be evaluated. 
Script is implemented by using the underlying programming 
language of Adept. Parameters are attached to the node such 
that, when executed, they are passed into the node. The 
script then manipulates and/or evaluates those parameters 
and returns a true, false or unknown value. 

2. Node Types 

The type of node used determines the role that the 
node plays within the procedure. The following is a brief 
description of the types of nodes within Adept and the role 
that they serve. Refer to Figure 4.3 for a representation 
of each node type. 

a. Start Node 

A start node is used at the beginning of a 
procedure and has only a true arc handle at the exit point. 
Adept" will execute a procedure if the start node of that 
procedure evaluates to true. 
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Jb. Work Node 


A work node can be identified as having three 
arc handles located at the top of the node that indicate the 
entryway into the node, and three other arc handles located 
along the bottom of the node that are used as exit points. 

A work node is used to indicate a decision point within the 
procedure. 

c. Case Node 

A case node is similar to a work node in that it 
has six arc handles and represents a single decision point. 
However, the true arc exit handle is located to the left of 
the node. Case nodes can be used alone and, when used in 
that manner, their role is identical to that of the work 
node. However, case nodes were originally designed to be 
used in conjunction with compound nodes in order to 
represent multiple decision points. A single case node 
would only be used in the event that a given procedure is 
complex and the readability of the procedure is of utmost 
importance. 

d. End Node 

An end node can be identified as having only 
three entrance point arc handles. This type of node is used 
to indicate the end of a procedure. Any given procedure can 
have one or more end nodes; one at the end of each path in 
the procedure. 
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e. Conpound Node 

A compound node can be any of the types 
discussed previously and is segmented into a series of three 
or more nodes, of varying styles, combined together into one 
node. Compound nodes can be grouped into two 
subtypes, 

(1) With Logical statements. Compound start, 
work, or end nodes are used either when a series of steps 
must be performed in one place or a decision needs to be 
made based upon the combined results of several decisions 
(Himes et al, 1991, p. 24), The first node of a compound 
start, work or end node will have either a programmer 
defined logical statement attached to it or it will have a 
default logical statement defined by Adept. The function of 
the logical statement is to identify how the individual 
segments, either separately or in combination, of the 
compound node are to be evaluated in order to determine the 
result of the overall node. If no programmer defined 
logical statement is attached to the node. Adept 
automatically combines the results of each of the individual 
segments as if they were linked together by logical AND 
operators. 

This Adept construct can be equated to the 
if/then constructs of traditional text-based programming 
languages which include logical and/or statements. An 
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example of a compound work node represented in traditional 

text-based programming would be as follows: 

IF the subject is an animal 

AND it has four legs 

AND it's fur has spots 

AND it has a mane 

AND it roars 

THEN it is a lion 

For a more detailed discussion of the various subtypes and 
styles of compound nodes, the reader is referred to the 
Adept Reference Manual. 

(2) Without Logical Statements. A Compound 
case node has no logical statements attached to it and is 
used to represent a multiple decision point with multiple 
exit points. In a compound case node, each node within it 
is evaluated separately, from top to bottom. Similar to the 
If/then/else or CASE constructs of traditional text-based 
programming, if the first node evaluates to true, then 
control will pass from the compound node to the node 
connected by the true arc from that node of the compound 
node. If the node evaluates to false, the next node in the 
chain is evaluated. If it evaluates to unknown, then Adept 
exits the compound case node at the unknown arc. This 
process is continued until either one of the nodes evaluates 
to true or unknown or all nodes evaluate to false. In the 
latter case. Adept will exit at the false arc. 


47 



E. STATEMENTS 


Statements are expressions that describe how Adept is to 
evaluate or perform a specific problem or task. These 
statements are located either to the right of a node or 
within the script of a node and specifically define the role 
that the node plays in the procedure. The similarity 
between Statements, in structure and terminology, to some 
standard programming language instructions will become 
apparent in the following discussion. 

There are four types of statements that Adept uses and 
their usage is dependent upon the style of node to which it 
will be attached. There are many combinations of statements 
and nodes that may be used by a programmer in the design of 
Adept expert systems. However, for the purpose of this 
thesis, only a brief overview of these statements are 
presented. Should a more indepth and detailed analysis of 
statements and their usage be required, the reader is 
referred to the Adept Reference Manual. 

1. General Statements 

As defined by Adept (Himes et al, 1991, p. 100), a 
general statement "is any expression that contains 
constants, variables, functions, objects, relational 
operators, assignment operators, arithmetic operators and 
logical operators". The following is a description of each 
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of the components that can be included in a general 
statement. 


• Constants can be text strings, reserved words or 
numbers. 

• Variables are symbols that can take on many 
values. 

• Functions are self-contained units consisting of a 
set of programming instructions. 

• Objects are those components found on the display 
screen. These include buttons, fields and 
check boxes. 

• Relational operators are operators, such as equal 
to or less than, which are used to compare two 
elements. 

• Assignment operators are used to assign a specific 
value to a variable. 

’ Arithmetic operators are those operators that 
allow mathematical manipulations to be performed 
on numerical values. 

• Logical operators are used to combine the results 
of two or more statements in order to obtain an 
overall result. 

2. Literal Statements 

As defined in the Adept Reference manual (1991, p. 
102), literal statements are expressions that do not contain 
operators, functions or objects. They contain the 
programmer's own words or phrases and are used to describe 
goals, tasks or results. An example of a literal statement 
would be Santa Claus is real. 
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3. Control Statements 


A control statement, as defined by the Adept 
Reference Manual (Himes et al, 1991, p. 103), "is a reserved 
word that defines the conditions under which Adept evaluates 
a group of general statements in a script". Control 
statements allow the programmer to control when certain 
tasks are performed based upon specific pre-defined 
conditions. Some of the reserved words include: 
if/then/else 
while/do 
do/until 
step 

4. Compound Statements 

These statements consist of a combination of one or 
more of the previously listed statement types. This type of 
statement is typically used in custom nodes when the 
programmer desires to pass more than one parameter into the 
node. 

The next chapter applies the structured methodology 
presented in chapter three to the Adept constructs discussed 
in this chapter. 
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V. STRUCTURED METHODOLOGIES FOR ADEPT 


This chapter is comprised of two main sections. The 
first is a presentation and discussion of guidelines for 
developing an expert system using the Adept expert system 
shell. These guidelines are based on the structured 
methodologies of traditional text-based programming 
languages as presented in Chapter III. The second is an 
application of those guidelines to the Performance module of 
the MK92 MOD 2 PCS MAES developed in an earlier effort. 

A. STRUCTURED METHODOLOGY GUIDELINES FOR ADEPT 

In order to maintain ease of cross referencing as well 
as readability, the same format used in chapter three on 
traditional structured methodologies is utilized in this 
chapter. As stated in Chapter III, a visual programming 
interface tends to create an overlap between the structured 
design and structured programming methodologies. As such, 
the application of one characteristic of the structured 
methodology can be contingent upon the application of 
another. 

1. Structure Charts 

Since an Adept application represents a system of 
independent modules called procedures^ structure charts 
should be used to partition the overall system into a top- 
down hierarchy of modules and submodules. This guideline 
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reflects a one to one correspondence between traditional 
text-based programming languages and Adept in the use of 
structure charts as a tool for the application of a 
structured design methodology, 

2. Modules 

As stated in Chapter III, a module represents a 
series of instructions or program statements that are 
grouped together to perform one solitary function. In 
Adept, modules are represented as procedures and the program 
statements are represented by nodes. An application can be 
broken down and factored out into a series of procedures, 
each performing a specific function within the application. 
As such, each procedure can be developed such that its 
function is known and has a well-defined role. But the 
details as to how the procedure performs the function is not 
known to, or required by, the other procedures in the 
application. In other words, each procedure can be designed 
as a black box. 

Each procedure can be designed to have only one 
input flow, mechanics and one function. However, in Adept, 
a procedure of moderate size can, and typically, have more 
than one output flow. For example, the procedure in Figure 
5.1 has three exit points; one for FCl ACQ F and two for 
FCIACQ Menu. In a traditional text-based programming 
language, having more than one exit would be confusing and 
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could cause a decrease in programmer comprehension and an 
increase in maintenance time. However, in Adept, by the 
very nature of the visual programming interface, the paths 
are easy to follow; therefore, making the exit points easy 
to locate. As such, the general rule that a module should 
have only one exit point can be relaxed in Adept. In fact, 
if the single-exit property of structured design and 
programming were to be applied to Figure 5.1, this procedure 
would need to be broken out into three distinct sub¬ 
procedures. This practice would sacrifice the functionally 
cohesive property of Figure 5.1 in order to maintain the 
one-exit property of a module. In addition, excluding the 
actions to be taken at the end of the paths, each sub¬ 
procedure would duplicate coding found in the other sub¬ 
procedures; a practice that is to be avoided in the 
application of structured design and programming 
methodologies. 

As in traditional text-based programming, factoring 
should be employed, where feasible, in order to reduce 
redundant coding and increase procedure reuse. If there are 
series of nodes, representing one function, that are 
repeated in two or more procedures within an Adept 
application, then these nodes should be factored out into a 
procedure of their own. An example of factoring out 
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redundant nodes is provided in Section B.3.b of this 
chapter. 

3. Intra-modular Design Characteristics 

Two characteristics of concern in Adept are module 
size and cohesion. The following sections discuss these 
two characteristics as well as the trade-offs between the 
two. 

a. Module Size 

The recommended maximiam size of a procedure in 
Adept is approximately 30 nodes. The reasons for this are 
two-fold. 

First, as more and more nodes are added to a a 
procedure, the complexity of the procedure increases, 
thereby decreasing the readability of the procedure. This, 
in turn, reduces programmer comprehension, thereby 
negatively impacting on the maintainability of the 
procedure. 

Second, because Adept is a visual programming 
language, the readability of a printed procedure decreases 
as the size and complexity of the procedure increases. The 
reason is that Adept can only print out large procedures in 
one of two ways. The first way is to shrink the procedure 
to such a size that would force it to fit onto one page. In 
this case, the nodes and statements in the procedure will 
either become extremely small or they will begin to overlap 
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onto each other. The second way is to separate the 
procedure into segments and print out each separately. In 
this event, the project engineer would then have to paste 
the individual printouts together in order to follow the 
logic of the procedure. In both cases, the logic of the 
printed procedure becomes very difficult to follow. 

Therefore, within the confines of the Adept 
programming language, it may become necessary to sacrifice 
functional cohesion in order to attain a module which is 
easy to comprehend, implement, maintain and reuse. 
b. Cohesion 

A project engineer, programming in the Adept 
expert system shell, should always attempt to achieve 
functionally cohesive procedures. That is, the procedures 
should be developed such that each one performs a solitary, 
well-defined function. Generally, this objective is 
relatively easy to obtain. However, as a direct result of 
the constraints that the Adept programming environment 
places upon module size, there will be ocassions where the 
higb-.'^st attainable level of cohesion will be sequential 
cohesion. This situation should not be a cause for alarm as 
sequential cohesion is still a very good and acceptable 
cohesion level. 
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c. Trade-off Between Cohesion and Module Size 

Given the above information, the following two 

questions need to be addressed: 

When should module size take precedence over 
the cohesion property of the module? 

• When module size is of primary concern, to_ 
what degree should cohesion be sacrificed in 
order to obtain a "good" module size? 

First, the reader must take into account that by the very 

nature of the constructs of Adept, it is very difficult for 

a procedure to achieve anything less than sequential 

cohesion. In Adept, all nodes within a procedure are always 

linked together via arcs as a sequence of steps. The only 

way for that link to be disrupted is if the project engineer 

forgot to attach an arc between the nodes. In this case, 

the program logic is flawed and the error will be discovered 

when running the application. Given that the achievement of 

sequential cohesion is still very good, it is the author's 

opinion, that the characteristic that takes precedence will 

ultimately depend upon the specific system that is being 

implemented and the system engineer's preference. A 

specific example of the trade-off between functional 

cohesion and module size will be provided in Section B of 

this chapter. 
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4. Inter-modular Design Characteristics 

When partitioning an application and designing 
procedures, the system engineer's primary concern is the 
degree of coupling between procedures. The more independent 
each procedure is from the others, the lower the degree of 
coupling and the better the design of the application. 

Adept passes information between procedures in two 
ways. One is via the result and goal style nodes and the 
other is via the use of global variables. 

a. Result and Goal Nodes 

As discussed in Chapter IV, result and goal 
style nodes are used primarily for forward and backward 
chaining throughout the application. In this case, only one 
variable is passed between procedures. This variable can 
take on only one of three possible values; true, false and 
unknown. This type of data passing is simple and 
uncomplicated and therefore exhibits good Data Coupling. 

b. Global Variables 

Although the use of global variables is dictated 
through standard programming conventions and not structured 
design or programming methodologies, they are mentioned here 
because they are the only other way in which information is 
passed from one procedure to another. In traditional text- 
based programming languages, global variables are those 
variables whose values are defined for the entire system and 
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are not passed as parameters from one module to the next. 
Global variables are typically assigned values that remain 
constant throughout the system and are used to provide a 
descriptive way to identify a constant. Standard 
programming conventions discourage the use of global 
variables when the assigned value does not remain constant. 
This is primarily due to the poor maintenance 
characteristics of global variables. If a global variable's 
value were to change as the program is executed, and it is 
not passed as a formal parameter from one module to the 
next, then an error in the variable can be passed, 
unchecked, from one module to the next. This, inturn, can 
complicate the maintenance of an application. This feature 
holds true in Adept. 

The use of global variables constitutes Common 
coupling which in traditional text-based structured design 
and programming methodologies is highly discouraged. 

However, as global variables are the only other way in which 
Adept can pass information, this rule can be relaxed if 
their use is warranted and they are used carefully. 

However, in many cases the utilization of global variables 
can be avoided in favor of local variables. However, when 
dealing with procedures that have a high reuse rate, the use 
of global variables whose values change can be a virtual 
necessity. A specific example is provided in Section B. 
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5. Other Good Deslgn/Programming Characteristics 

The remaining characteristics of the structured 
methodology to be applied to Adept are restrictivity, 
generality, fan-out and fan-in. The following discusses 
these characteristics in more depth. 

a. Restrictivity/Generality 

The manner in which this characteristic is 
applied in Adept corresponds exactly to the manner in which 
it is applied in traditional text-based programming 
languages. Like a program, a procedure in Adept can be made 
to be restrictive or general to such a degree that it limits 
the procedure's capability to be reused within the system. 

In order to determine if a procedure is too restrictive nor 
too general, the system engineer must step back and review 
the application as a whole. He/she must then determine the 
rate at which an application uses a specific procedure. If 
a module is used minimally in the application, then he/she 
may want to review the procedure to ensure that it is 
neitner too restrictive nor general. It should be noted 
that a procedure which displays restrictive or general 
properties is not necessarily a bad procedure. There are 
some cases where the presence of these types of procedures 
in an expert system is necessary in order to fulfill a 
specific requirement specified in the knowledge document. 

The necessity of this type of procedure will ultimately be 
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dete-inined by the system engineer(s) and the domain 
expert(s) of the application under development. 

Jb. Fan-in and Fan-out 

As stated in Chapter III, fan-in equates to 
module reuse. In Adept, as in traditional text-based 
prograinming languages, there can never be too much procedure 
reuse provided that the procedures exhibit good cohesion and 
their parameter interfaces are not sacrificed. Fan-out, on 
the other hand, indicates the number of subordinates 
stemming from any given procedure. In Adept, fan-out is 
dictated by module size in addition to the psychological 
reasons presented by traditional text-based programming 
languages. Similar to the text-based programs, the general 
rule for the number of child procedures stemming from any 
one parent procedure is approximately seven. However, 
because a procedure's size is restricted within the confines 
of the Adept programming environment, that number may be 
increased in order to preserve programmer comprehension. 
These module size constraints were discussed in a previous 
section of this chapter. 

B. APPLICATION OF STRUCTURED TECHNIQUES FOR VISUAL 

PROGRAMMING AND DESIGN TO THE PERFORMANCE PROTOTYPE 

This section provides a brief description of the 
prototyping technique of systems development, how that 
technique was applied to the initial development of the 
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Performance module and the application of the structured 
techniques for visual programming in Adept to the initial 
Performance prototype. 

1. Prototyping 

As defined by VJhitten et al (1989, pp. 124, 414), 
prototyping is a first full-scale, and usually functional, 
working model of a system or subsystem. Prototyping is a 
technique that is typically used when the end users or, in 
this case, the domain experts can not easily define a 
complete set of systems requirements in one iteration. As 
such, as the prototype is developed, the domain experts test 
the system and recommend modifications to the system based 
upon requirements, methods and format. This cycle continues 
until the system is accepted by the users. There are 
advantages and disadvantages to using the prototyping 
technique. Some of the advantages and disadvantages are as 
follows: 

a. Advantages 

• Encourages the domain experts to become more 
active in systems development. 

• Allows for iterative development which is 
beneficial to expert system development. 

• Provides domain experts with a tangible 
product. 

• Errors are detected earlier in the SDLC. 

• Accelerates the definition, design, and 
construction phases of the SDLC. 
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Jb. Di sadvan tages 


• Prototyping tends not to promote a thorough 
application of structured analysis and design 
methodologies. 

• Systems engineers tend to use the prototype as 
the sole source of specifications. However, 
paper specifications are still a necessity 
when utilizing the prototyping technique 
(Whitten et al, 1994, p. 492) 

• Can lead to "premature commitment to a 
physical design" (Whitten et al, 1989, p. 

417) . 

• "Overreliance on prototyping tends to lead to 
development of technological approaches that 
don't always solve problems and fulfill 
requirements" (Whitten et al, 1989, p. 417). 

• Tends to stifle process improvement as the 
first solution is often the one implemented. 

When using the prototyping technique of system 

development, it is important to remember that prototyping is 

not a replacement for standard design and programming 

methodologies or the SDLC. It is to be used as a conplement 

to structured methodologies and the SDLC. 

2. Initial Performance Module Prototype 

The Performance module was initially constructed as 
a first subsystem prototype for the MAES. In the early 
phases of the prototyping process, the programmers faced a 
steep learning curve as they were not only required to learn 
the Adept expert system shell, but also the terminology and 
the concepts associated with the MK92 MOD 2 PCS. As such, 
it was determined that the best approach to knowledge 
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implementation would be to segment the Performance module 
knowledge document into readable and maintainable modules 
and represent them in the form of a structure chart (Lewis, 
1993, Appendix A and Smith, 1993, Appendix A). The 
knowledge was then implemented in Adept, exactly as it 
appeared in the structure chart, using forward chaining. 

Once all the modules of the knowledge document were 
implemented, the initial prototype was given to the domain 
experts for review. 

Upon review of the Performance module prototype the 
domain experts were able to determine that modifications 
were required. The initial knowledge document lacked 
pertinent information which affected the program logic of 
the prototype. As such, the domain experts sent revised 
knowledge documents back to the project engineers for 
implementation. This cycle continued until May 1994, when 
it was determined that the Performance module was functional 
in the sense that it duplicated, to the extent feasible, the 
procedures that the domain experts would follow in the 
diagnosis of the MK92 M0D2 PCS Performance module system 
defaults. 

Once the prototype was completed and functional, the 
project managers and project engineers needed to determine 
if the current software was suitable to handle 
implementation of the entire system or if the system should 
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be reprograiraned in a traditional text-based programming 
language. Although by no means all inclusive, the following 
questions were representative of what was considered in the 
decision process: 

Will the overall system be used on a PC or a 
mainframe? 

Is the prototype software effective, efficient, and 
easily maintainable by system programmers? 

Will the software still be effective, efficient, and 
easily maintained if developed on a large scale? 

Upon review of current system requirements, it was 

determined that the Adept expert system shell would be used 

to develop the production version of the MAES. It was also 

decided that the Performance prototype should be 

restructured by applying sound structured design and 

programming methodologies. 

The following section addresses the reconstruction 

of the Performance Module Prototype employing the guidelines 

presented in Section A of this chapter. 

3. Reconstruction of the Performance Prototype 
In applying a structured methodology to the 
Performance prototype, the first task was to determine if it 
would be necessary to discard the entire prototype in favor 
of total redevelopment or if reconstruction of the current 
prototype would be a more viable option. Since the 
prototype fulfilled user specifications and the current 
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application software was adequate for the iyiK92 MAES 
application, the project engineers opted to restructure the 
current prototype via the application of structured design 
and programming methodologies. 

The purpose of the following discussion is two-fold. 
First it will provide the reader with an example of how the 
guidelines of the structured methodology can be applied to 
an actual system. Secondly, it will serve as the basis by 
which the Performance prototype will be re-structured. For 
the ease of readability and cross-referencing between 
chapters, the format of the following section will be the 
same as in chapter three. In addition, not all aspects of 
the reconstruction will be presented here as it would be 
extremely tedious to mention every single modification to 
the prototype. Rather, a new structure chart, after 
application of the new structured methodology, of the 
Performance prototype is provided in Appendix A. 

a. Structure Charts 

When a prototyping technique is used in the 
development of information systems, the process of 
developing structure charts becomes iterative in nature. As 
user specifications are re-defined and updated, the 
structure charts must be updated to accurately reflect the 
true structure of the evolving prototype. 
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As stated previously, the project engineers used 
a prototyping technique in the development of the 
Performance module of the MK92 MAES. Structure charts were 
developed in the initial design stages of the prototype and 
were updated as modifications were made to both the user 
specifications and the prototype. 

Although there are no modifications to the user 
specifications at this time, the structure charts needed to 
be modified in order to reflect the changes in the prototype 
due to the application of the structured design and 
programming methodologies. These are provided in Appendix 
A. 

b. Modules 

The project engineers did a good job in 
segregating the application into a series of independent 
procedures which exhibited the black box properties of 
modularization. However, factoring and module reuse 
techniques were not fully applied throughout the 
application. 

First, some procedures contained functions that 
should have been factored out into separate procedures as 
the use of these functions were required by other modules. 
Figure 5.2 is such a procedure. Notice that this procedure, 
called FC2 ACQ E, has two start-result nodes; one labeled 
FC2 ACQ Ed and the other labeled 
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Figure 5.2: FC2 ACQ E Procedure 
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FC2 ACQ E. As designed, those nodes directly below and 
attached to the FC2 ACQ Ed start node may be triggered not 
only by the FC2 ACQ E procedure, but also by other 
procedures in the application. Since this series of nodes 
is triggered by other procedures outside of the one in which 
they are a part, these nodes should be factored out of this 
procedure and placed in a separate procedure of their own. 
There are a total of 16 modules that exhibit this trait. 

Second, there are several modules within the 
prototype that perform identical functions and could be 
collapsed together to increase module reuse. This was one 
of the primary design and implementation flaws of the 
prototype. One such example is within the FCl Track Bearing 
and Track Elevation modules of the prototype. Each of these 
modules has 11 subordinate modules. When compared against 
one another, their functions are identical. Specifically, 
Figure 5.3 is a subordinate module of FCl Track Bearing 
called Low XTAL Current and Figure 5.4 is a subordinate 
module of FCl Track Elevation called ELVTN Low XTAL Current. 
These two modules are identical with the exception of the 
following: 

One procedure reviews "Delta B XTALS" while the 
other reviews "Delta E XTALS". 

♦ The replacement card numbers are different. 

• The result nodes refer to different modules. 
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These modules can be collapsed together and 
custom nodes used in order to account for the differences 
listed above. Collapsing these modules would reduce the 
overall size of the prototype by 11 procedures. There are 
several places in the prototype where similar situations 
occur. Once all of the redundant modules are eliminated, it 
is estimated that the prototype could be reduced by 
approximately one third of it original size. 

c. Intra-modular Design Characteristics 
The two primary intra-modular design 
characteristics of concern are cohesion and module size. In 
most cases, functional cohesion was attained in the modules 
located in the upper levels of the system without 
sacrificing module size. However, in the lower levels, the 
project engineers sacrificed functional cohesion for module 
size. Where this occurred, the lowest level of cohesion 
attained was Sequential cohesion. For example, Figures 5.5 
and 5.6 are two separate procedures within the FC2 Track 
Elevation module. Figure 5.6 was factored out as a 
subordinate module to Figure 5.5. The only purpose of 
factoring out FC2 TELVTN Case 31 into a module of its own 
was to preserve module size. 

Which characteristic should take precedence? In 
this particular case, the solution is obvious. It would be 
easiest to factor out those nodes, in FC2 TELVTN Case 3 . 


72 



"FC2 Track Elevation NoGo 



73 





4 




below the compound node and create another module. However, 
there will be some cases were a cut-off point will not be so 
obvious and it will be up to the project engineers to 
decide. 

d. Inter-modular Design Characteristics 

Throughout the Performance prototype, most 
procedures exhibited Data coupling which is the lowest 
degree of coupling attainable. There are three pieces of 
data that are passed from module to module; Title, Subtitle, 
and the value (true, false, or unknown) of the last 
evaluated node of the calling module. The first two pieces 
of data are passed through the use of global variables. 
Although the use of global variables should be avoided, 
given the nature of the constructs of Adept, the project 
engineers were left with no other viable alternative. Since 
all modules contain displays that require these inputs, the 
project engineers would have had to invent new variable 
names for each module in the prototype in order to avoid the 
use of global variables. In the procedures that were not 
used as common modules, the global variables were treated as 
local variables and redefined at the beginning of the 
procedure, thereby attaining Data coupling. However, the 
common procedures will have the values of the global 
variables passed to them from other procedures. As such, 
these modules only attained Content coupling. 
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e. Other Design Programming Characteristics 
As stated in Chapter III, these 
characteristics include Restrictivity/Generality, Fan-out, 
and Fan-in. Upon application of the design characteristics 
mentioned previously, none of the procedures in the 
Performance prototype will be either to restrictive or too 
general. This is primarily because of the module size issue 
presented earlier. The Fan-in of the prototype will 
increase as redundant modules are collapsed together to 
promote procedure reuse. There was no instance in the 
prototype where there was too much Fan-out. The largest 
number of child procedures assigned to any given parent 
procedure in the Performance prototype is six. 

The next chapter discusses the lessons learned and 
insights gained by the author during the development of this 
thesis. 
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VI. LESSONS LEARNED AND CONCLUSIONS 


This chapter discusses the lessons learned during the 
impleinentation of the structured design and progranutiing 
methodology developed in chapter three and the invaluable 
insights gained by the author as a result of the work on 
this thesis. Most of the lessons learned revolve around the 
Performance module prototype of the MK92 MOD 2 FCS MAES. 
Uninterestingly enough, and also most frustrating, is that 
almost every lesson learned during this project was mot a 
new revelation. The problems encountered during this thesis 
were the same ones that have been identified repeatedly by 
many information system professionals for years as being 
common problems found with most information system 
development projects. The purpose of restating them here is 
to reinforce what has already been presented in. numerous 
structured analysis, design and programming text books and 
what has been taught in many courses attended by 
undergraduate and graduate students alike. This knowledge, 
however, did not preclude students frorti repeating the same 
errors. Only practice provides a deep understanding of 
these issues and an appreciation of the techniques to avoid 
them. 


77 


The lessons learned can be broken up into two general 
categories; design and implementation issues and 
documentation issues. 

A. DESIGN AND IMPLEMENTATION ISSUES 

Many of the problems encountered with the design and 
implementation of the Performance module prototype were 
caused by the following: 

• lack of adherence to the analysis and design 
phases of the SDLC 

• lack of a thorough application of a structured 
design and/or programming methodology 

• lack of the application of standard programming 
conventions. 

These issues were addressed in previous chapters; 
however, they are restated briefly here as to emphasize 
their importance as valuable lessons learned. 

1. Lack of Adherence to System Development Life Cycle 
As discussed in Chapter V, one of the purposes for 
employing the prototyping technique is to accelerate the 
definition, design, and construction phases of the SDLC, not 
eliminate them. However, as is typical, the use of 
prototyping usually tends to promote the incomplete 
application of the analysis and design phases of the SDLC. 
The initial Performance prototype was implemented using a 
piecemeal process. The complete set of user specifications, 
or in this case the documented knowledge, was not available 
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for review prior to initiating the actual coding of the 
system. As such, the overall structure of the prototype 
suffered greatly. 

In order to avoid these types of problems, system 
engineers should adhere to and follow through on all phases 
of the SDLC during the development of an information system, 
regardless of the tools that are used to complement it. 

2. Lack of Thorough Application of Structured Design 
and Prograiraning Methodologies 

The use and application of a structured design 
and/or programming methodology was not thoroughly applied 
during the initial development of the Performance prototype. 
As such, the prototype was not well-defined and lacked 
characteristics that contribute to the overall readability, 
flexibility, standardization and maintainability of the 
prototype. Chapter V examined the problems associated with 
the deficiencies of the initial prototype and how those 
problems can be rectified through the application of a 
structured design and programming methodology. 

3. Lack of Application of Standard Programming 
Conventions 

The initial prototype did not fully apply the 
techniques of standard programming conventions. Some of 
these include the lack of standardized procedure naming 
conventions and internal documentation. Although these 
conventions are not considered a requirement of the 


79 


structured programming methodology, their application would 
contribute to the readability, standardization and 
maintainability of the system. For example, internal 
documentation is important as it provides the programmer 
with valuable information about a specific module, thereby 
improving programmer comprehension and thus contributing to 
the reduction of maintenance time. As such, standard 
programming practices should be applied where feasible in 
order to increase programmer comprehension and the 
maintainability of the system. 

B. DOCUMENTATION ISSUES 

The need for documentation standards underscores a common 
failure of many analysts--the failure to document as an 
ongoing activity during the life cycle....Most of us tend 
to post-document software. Unfortunately, we often carry 
this bad habit over to system's development. (Whitten et 
al, 1994, p.93) . 

Although the design and implementation issues, stated 
previously, contributed to the poor maintenance 
characteristics of the original prototype, they were not the 
sole contributor to the problem. The lack of thorough 
external documentation made the maintenance of the prototype 
very difficult. The following is a discussion of these 
issues. 

1. Initial Docximentatlon 

The documentation of the initial prototype software 
was limited and that which was available was scattered and 
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unorganizGCl. As is typical, most of ths docurnGiitation 
appearsd to have been done after the actual implementation 
of the knowledge document. The lack of thorough 
documentation caused the learning curve of the follow on 
project engineers to increase tremendously. In order to 
revise the prototype, the project engineers first had to 
decipher how the prototype was designed/implemented, and to 
determine if a special methodology had been applied during 
the design/implementation, and if so, what was it and why 
was it used? This deficiency was corrected through the 
organization of the available documentation and the 
incorporation of additional known information that was 
pertinent to the last five revisions of the prototype. 
Beginning with Revision B, binders were developed for each 
version of the Performance prototype. Each binder contains 
the following information: 

the knowledge document 

• a printout of the Adept procedures 

the knowledge document modification requests 
provided by the domain experts 

the project engineer's notes regarding the 
developement process, standards used, etc... 

• a backup copy of the prototype's programming code 
on 3.5" diskettes 

In addition, all theses, pertaining to the 
development of the MK92 MOD 2 FCS MAES should be integrated 


81 


into one document. All documentation should be actively 
maintained as requirements dictate. 

2. Prototype Modifications 

Standard practice during the development and 
revision of a CBIS is to maintain all documentation that 
reflects the initial development of the system plus any 
modifications made to that system thereafter. Such 
documentation is maintained until the CBIS has been tested, 
evaluated, and approved for distribution. At which time, 
only that documentation which describes the final version of 
the system is required to be maintained. This includes such 
documentation as structure charts, module interfaces, and 
data dictionaries. 

The initial prototype went through two iterations of 
revisions prior to submission for testing and evaluation. 

The available documentation provided no insight as to what 
the first iteration prototype consisted of nor was there any 
information on how and why the prototype had been modified. 
Had r.his been the final version of the prototype, this would 
not have been a problem. However, five months after the 
initial prototype was submitted, it was discovered that the 
domain experts had at least two more sets of revisions that 
still needed to be implemented. These revisions were of 
particular importance as their implementation changed the 
actual logic of the prototype. The revisions, according to 
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the domain experts, had been put on hold by the project 
engineers due to time constraints. None of this was 
indicated in the documentation and therefore unknown to the 
project managers. This faux pas extended the scheduled 
project completion date by an additional six months. 

All dociamentation, pertinent to the development of 
the MK92 MOD 2 PCS MAES, should be co-located with the 
prototype until project completion. As such, any additional 
requests for modifications should be forwarded to the 
project engineers for incorporation into the established 
documentation dicussed in the previous section. 

3. Knowledge Dociimentatlon 

The initial knowledge documentation, submitted to 
the NPS project team, was handwritten and fairly clear. 
However, as modifications were requested and implemented, 
the original document was scratched over and the 
modifications handwritten on to the original document. This 
process continued through all five revisions of the 
prototype. Eventually, parts of the document have become 
very difficult to read and interpret. Figure 6.1 is an 
example of one such knowledge document. In future revisions 
to the Performance module, or in the development of other 
modules of the system, it is recommended that the knowledge 
docu'.aent be transferred to the computer using graphical 
software such as VISIO or allCLEAR. As modifications are 
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made, the knowledge document can be modified and a clean 
copy printed and maintained. This is presently being done 
by NPS support staff. 

In addition, the knowledge doctiment should be 
factored out into modules that more closely approximate the 
actual procedures implemented in Adept. Although not of 
major importance, it would enhance the cross referencing 
between the knowledge document and the actual prototype. 

Finally, a document should be written that describes 
the knowledge document itself. During the second revision 
to the prototype, numbers were added to the knowledge 
document to indicate the association between the specific 
Help screens, listed on a separate document, to specific 
nodes within the knowledge document. Later in the 
development process, when new people joined the project and 
the original project engineers were gone, it was difficult 
to ascertain the purpose of those niimbers. 

C. INSIGHTS AND CONCLUSIONS 

The development of a new structured design and 
programming methodology for use with expert system shells 
using a visual programming language has been challenging. 

It has provided the author with invaluable insights into the 
evol’^’ing characteristics of fourth generation languages 
(4GLs) and how their usage impacts the application of 
traditional structured programming methodologies. 
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Of particular interest was the correlation between the 
increasing technology of programming languages and the 
decreasing need to utilize professionally trained, 
traditional text-based programmers in the development of 
some of the more simplistic CBISs. The reason for this is 
that as the technology of programming languages continues to 
improve in order to accommodate a less technically oriented 
user, the need for the application of traditional text-based 
structured programming methodology decreases. The degree to 
which this correlation holds true is contingent upon the 
specific 4GL used and the size and complexity of the system 
to be built. In Adept, many of the more tedious aspects of 
a structured programming methodology, required in the 
development of traditional text-based programs, fade away 
completely or overlap into structured design. 

One problem encountered during the development of this 
thes’.s was the determination of the degree to which this new 
structured methodology could be applied to other 4GLs 
employing visual interfaces. Unlike its predecessor's, this 
structured methodology is based upon 4GLs whose utilization 
and application have only recently evolved. The authors of 
traditional text-based structured programming methodologies 
developed them after years of tedious, grueling, and time- 
consuming programming experience with many different second 
and third generation languages and have continued to expand 
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and refine them as appropriate. The structured methodology- 
developed in chapter five is predicated upon the constructs 
of the Adept expert system shell only. As such, the 
structured methodology developed in this thesis may need to 
be modified in order to accommodate the specific nuances of 
the 4GL to which it will be applied. 
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APPENDIX A 


STRUCTURE 

A. MAIN MENU 

Name: 

Description: 

Called by: 
Calls: 

Name: 

Description: 

Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 


CHARTS AND PROCEDURE FUNCTION DESCRIPTIONS 


PROCEDURES 

Main Menu (Figure 1) 

The first menu in the program. Allows 
selection of the Performance or Calibration 
modules of the diagnostic program or exits 
the program. 

Initiation of the MK92 Fire Control System 
Maintenance Advisor Expert System. 

Performance and Calibration Menus. 


Performance Menu 

Allows the selection of FCl, FC2 or FC4 and 
FC5 Menus. 

Main Menu 

FCl, FC2 or FC4 and FC5 


Calibration Menu 

Allows the selection of the Calibration 
procedures. 

Main Menu 

Calls Calibration CAS or STIR 
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B. FCl PROCEDURES 


Name: 

FCl Menu (Figure 2) 

Description: 

Allows selection of FCl Designation, 
Acquisition and Track procedures. 

Called by: 

Performance Menu 

Calls: 

FCl DTRB Menu, FCl ACQ Menu, and FCl TBER 

Menu. 

Name: 

FCl DTRB Menu 

Description: 

Allows selection of FCl Designation Track, 
Range and Bearing procedures. 

Called by: 

FCl Menu 

Calls: 

FCl DT Menu, FCl DR and FCl DB 

Name: 

FCl ACQ Menu 

Description: 

Allows selection of FCl ACQ procedures. 

Called by: 

FCl Menu 

Calls: 

FCl ACQ Menu 

Name: 

FCl TBER Menu 

Description: 

Allows selection of FCl Track Bearing, 
Elevation and Range procedures. 

Called by: 

FCl Menu 

Calls: 

FCl TBE Menu and FCl TR Menu 


90 









C. FCl DESIGNATION TIME PROCEDURES 


Name: FCl DT Menu (Figure 3) 

Description: Allows selection of one of three possible FCl 

Designation Time trouble-shooting paths: Case 
1 (range reading on TOTE is not the same as 
range gate position, DT Submenu or No range 
gate movement. 

Called by: FCl DTRB Menu 

Calls: FCl DT Case 1, FCl DT Submenu, and FCl DT No 

Rng Gte Mvmt A. 


Name: 

Description: 

Called by: 

Calls: 

FCl DT Case 1 

Allows trouble-shooting of 

FCl DT Menu 

FCl DT Case lA 

Case 1 procedures. 

Name: 

FCl DT Case lA 


Description: 

Continues trouble-shooting 

Case 1. 

Called by: 

FCl DT Case 1 


Calls: 

None 



Name: FCl DT Submenu 

Description: Allows selection of one of four possible 

track antenna and range gate movements. 

Called by: FCl DT Menu 

Calls: FCl DT No Trk Ant Mvmt, FCl DT Trk Ant Mvmt 

Slow, FCl DT No Rng Gte Mvmt, FCl DT Rng Gte 
Mvmt Slow. 
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Name: 


Description: 


Called by: 


Calls: 


FCl DT No Trk Ant Mvmt 

Allows trouble-shooting of FCS in the event 
that the track antenna does not move in FCl 
designation time. 

FCl DT Submenu 

FCl DT No Trk Ant Mvmt A 


Name; 


Description: 


FCl DT No Trk Ant Mvmt A 

Continues trouble-shooting procedures for no 
movement of track antenna in FCl designation 
time. 


Called by; 


FCl DT No Trk Ant Mvmt 


Calls: 


None. 


Name: 


Description: 


Called by: 


Calls: 


FCl DT Trk Ant Mvmt Slow 

Allows trouble-shooting of FCS in the event 
that the track antenna moves too slowly in 
FCl designation time. 

FCl DT Submenu 

None 


Name: 


Description: 


Called by: 


FCl DT No Rng Gte Mvmt 

Allows trouble-shooting of FCS in the event 
that there is no range gate movement in FCl 
designation time. 

FCl DT Submenu 


Calls: 


FCl DT No Rng Gte Mvmt A 
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Name: 


FCl DT No Rng Gte Mvmt A 


Description: 


Called by: 
Calls: 


Name. 

Description: 

Called by: 
Calls: 


This procedure can either be executed as a 
continuance of trouble-shooting procedures 
for no movement of the range gate in FCl 
designation time or it can be called directly 
from the main DT Menu as the situation 
dictates. 

FCl DT No Rng Gte Mvmt and FCl DT Menu 
None 


FCl DT Rng Gte Mvmt Slow 

Allows trouble-shooting of FCS in the event 
that the range gate moves too slowly in FCl 
designation time. 

FCl DT Submenu 

None 
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D. PCI DESIGNATION RANGE PROCEDURES 


Name: 

Description: 

Called by: 
Calls: 


Name • 

Description: 


Called by: 
Calls: 


FCl DR A (Figure 4) 

Allows trouble-shooting of problems 
associated with FCl Designation Range. 

FCl DTRB Menu 

FCl DR B 


FCl DR B 

This procedure is common to and a continuance 
of both FCl designation range and FCl 
designation bearing trouble-shooting 
procedures. In this instance, it continues 
the trouble-shooting procedures for FCl 
Designation Range. 

FCl DR A and FCl DB 

None 
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Figure 4: FCl Designation Range A 
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E. FCl DESIGNATION BEARING PROCEDURES 


Name: 

Description: 

Called by: 
Calls: 


Name: 

Description: 


Called by: 
Calls: 


FCl DB (Figure 5) 

Allows trouble-shooting of the FCS 
designation bearing in FCl. 

FCl DTRB Menu 

FCl DR B 


FCl DR B 

This procedure is common to and a continuance 
of both FCl designation range and FCl 
designation bearing trouble-shooting 
procedures. In this instance, it continues 
the trouble-shooting procedures for FCl 
Designation Bearing. 

FCl DR A and FCl DB 

None 
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F. PCI ACQUISITION PROCEDURES 


Name: 

FCl ACQ Menu (Figure 6) 

Description: 

Allows selection of one of four possible 
trouble-shooting paths of FCl Acquisition. 

Called by: 

FCl Menu 

Call;?: 

FCl ACQ Elev Scan Video Present, FCl ACQ 

Video Present Ant Scans, FCl ACQ D and FCl 

ACQ E 

Name: 

FCl ACQ Elev Scan Video Present 

Description: 

Allows trouble-shooting of FCl Acquisition in 
the event that the elevation scans and video 
is present. 

Called by: 

FCl ACQ Menu 

Calls: 

FCl ACQ B 

Name: 

FCl ACQ B 

Description: 

Continues trouble-shooting of FCl Acquisition 
elevation scans and video present. 

Called by: 

FCl ACQ Elev Scan Video Present 

Calls: 

None 

Name: 

FCl ACQ Video Present Ant Scans 

Description: 

Allows trouble-shooting of FCl Acquisition in 
the event that the video is present and the 
antenna scans. 

Called by: 

FCl ACQ Menu 

Calls: 

FCl ACQ F 
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Name: 

FCl ACQ F 

Description: 

Continues trouble-shooting of FCl ACQ Video 
Present Ant Scans by checking the video at 
the video modulator. 

Called by: 

FCl ACQ Video Present Ant Scans 

Calls: 

FCl TBE Case 21 

Name: 

FCl TBE Case 21 

Description: 

This procedure is common to FCl Acquisition 
and FCl Track Bearing and Elevation._ In this 
instance, it continues trouJble-shooting 
procedures of FCl Acquisition module F. 

Called by: 

FCl ACQ F 

Calls: 

None 

Name: 

FCl ACQ D 

Description: 

Allows trouble-shooting of FCl Acquisition by 
checking for antenna movement in elevation in 
WCC (manual mode). 

Called hy: 

FCl ACQ Menu 

Calls: 

None 

Name: 

FCl ACQ E 

Description: 

Allows trouble-shooting of FCl Acquisition by 
checking the crystal current readings and 
allowing the selection of one of three 
possible paths; check track receiver 1£) 
sample readings, check RF input at UD401/D-U2 
or A2 and A7 inputs. 

Called by: 

FCl ACQ Menu 

Calls: 

FCl ACQ A, FCl ACQ C, and FCl ACQ Eb 
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Name: 


FCl ACQ A 


Description: 

Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 


Continues trouble-shooting of FCl Acquisition 
crystal current readings by checking the 
track receiver LO sample readings. 

FCl ACQ E 

FCl ACQ Aa 


FCl ACQ Aa 

Continues trouble-shooting of FCl Acquisition 
track receiver LO sample readings by checking 
the TR tubes at UD401). 

FCl ACQ A 

None 


FCl ACQ C 

Continues trouble-shooting of FCl Acquisition 
crystal current readings by checking the A2 
and A7 inputs. 

FCl ACQ E 

None 
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G. FCl TRACK BEARING AND ELEVATION PROCEDURES 

Name: FCl TBE Menu (Figure 7) 

Desc.-'iption: Allows selection of one of three possible 

track bearing and elevation paths; Nogo PDT 
mode, NoGo PAT mode or NoGo both modes. 

Called by: FCl TBER Menu 

Calls: FCl TBE NoGo PDT Mode, FCl TBE NoGo PAT Mode 

and FCl TBE NoGo Both Modes 


Name: FCl TBE NoGo PDT Mode 

Description: Allows trouble-shooting of FCl Track Bearing 

or Elevation in the event that there is a 
NoGo in PDT mode. 

Called by: FCl TBE Menu 

Calls: FCl TBE C 


Name: FCl TBE C 

Description: This procedure is common to all of the three 

primary Menu selections in FCl TBE Menu. In 
all cases it continues trouble-shooting 
procedures for the appropriate NoGo mode. 

Called by: FCl TBE NoGo PDT Mode 

Calls: None 


Name: FCl TBE NoGo in PAT Mode 

Description: Allows trouble-shooting of FCl Track Bearing 

or Elevation in the event that there is a 
NoGo in PAT mode. 

Called by: FCl TBE Menu 

Calls: FCl TBE C (described above) 
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Name: 

FCl TBE NoGo Both Modes 

Description: 

Allows trouble-shooting of FCl Track Bearing 
and Elevation in the event that there is a 
NoGo in both PDT and PAT modes. It allows 
selection of one of three possible paths. 

Called by: 

FCl TBE Menu 

Calls: 

FCl TBE Trk Ant Oscillations, FCl TBE Low 

XTAL Current and FCl TBE F 

Name: 

FCl TBE Low XTAL Current 

Description: 

Allows trouble-shooting of FCl Track Bearing 
and Elevation NoGo in both PDT and PAT modes 
in the event that the crystal current is low. 

Called by: 

FCl TBE NoGo Both Modes 

Calls: 

FCl TACQ A 

Name: 

FCl TACQ A 

Description: 

Continues trouble-shooting of FCl Track 
Bearing and Elevation by checking the track 
receiver LO sample in track acquisition. 

Called by: 

FCl TBE Low XTAL Current 

Calls: 

FCl TACQ Aa 

Name: 

FCl TACQ Aa 

Description: 

Continues trouble-shooting of FCl Track 
Bearing and Elevation by checking the TR tube 
readings at UD401. 

Called by: 

FCl TACQ A 

Calls: 

None 
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Name: 


FCl TBE Trk Ant Oscillations 


Description: 

Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 

Name: 

Description: 

Called by: 
Calls: 


Allows trouble-shooting of FCl Track Bearing 
and Elevation in the event that there are 
track antenna oscillations. 

FCl TBE NoGo Both Modes 

FCl TBE F 


FCl TBE F 

This procedure, and its associated sub¬ 
procedures, is a commonly used procedure in 
FCl TBE NoGo both modes. It can be selected 
directly from the FCl TBE NoGo Both Modes 
procedure or it can used to continue trouble¬ 
shooting of FCl Track Bearing and Elevation 
track antenna oscillations by checking the 
video level tolerance. 

FCl TBE Trk Ant Oscillations and FCl TBE NoGo 
Both Modes 

FCl TBE D and FCl TBE C (described above) 


FCl TBE D 

Continues trouble-shooting of FCl TBE F by 
checking the continuity of the AGC video 
level. 

FCl TBE F 

FCl TBE Case 2 and FCl TBE Case 3 
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Name: 

FCl TBE Case 2 

Description; 

This procedure is common in trouble-shooting 
track antenna oscillations or videcp level 
tolerance checks. In both cases, it is used 
to continues trouble-shooting of video levels 
in the event that the sigma video level is 
out of tolerance. 

Called by: 

FCl TBE F and FCl TBE D 

Calls: 

FCl TBE Case 21 

Name: 

FCl TBE Case 21 

Description: 

Continues trouble-shooting of FCl TBE Case 2 
by checking for the sigma video presence at 
UD403/PanB-TP4. 

Called by: 

FCl TBE Case 2 

Calls: 

FCl TBE E 

Name: 

FCl TBE E 

Description: 

Continues trouble-shooting of FCl TBE Case 21 
by checking the inputs at UD401/C-B/16. 

Called by: 

FCl TBE Case 21 

Calls: 

None 

Name: 

FCl TBE Case 3 

Description; 

Continues trouble-shooting of video levels in 
the event that the sigma video level is in of 
tolerance, but the delta video levels are out 
of tolerance. 

Called by: 

FCl TBE D 

Calls: 

None 
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FCl TBE E 
(UD401/C-B/16 Input 



Figure 7: FCl Track Bearing and Elevation Menu 


FCl TBE Menu 
(Track Bearing and 
Elevation). 























H. FCl TRACK RANGE PROCEDURES 


Name: 

Description: 

Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 


Name: 

Description: 

Called by: 

Calls: 


FCl TRNG Menu (Figure 8) 

Allows trouble-shooting of FCl Track Range 
procedures by allowing selection of one of 
three possible paths: NoGo in PAT mode, NoGo 
in PDT mode and NoGo in both PAT and PDT 
modes. 

FCl TBER Menu 

RNG NoGo PAT Mode Only, RNG NoGo PDT Mode 
Only and RNG NoGo in Both Modes. 


RNG NoGo PAT Mode Only 

Allows trouble-shooting of FCl Track Range in 
the event that there is a NoGo in PAT mode. 

FCl TRNG Menu 

FCl TRNG C 


FCl TRNG C 

This procedure is common to all three of the 
NoGo modules of FCl Track Range. In this 
instance, it continues trouble-shooting of a 
NoGo in PAT Mode via gradient adjustments in 
PAT and PDT modes. 

RNG NoGo PAT Mode Only, RNG NoGo PDT Mode 
Only and FCl TRNG D 

None. 
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Name: 

Description: 

Called by: 
Calls: 


RNG NoGo PDT Mode Only 

Allows trouble-shooting of FCl Track Range in 
the event that there is a NoGo in PDT mode. 

FCl TRNG Menu 

FCl TRNG C (described above) 


Name: 

Description: 

Called by: 
Calls: 


RNG NoGo Both Modes 

Allows trouble-shooting of FCl Track Range in 
the event that there is a NoGo in PDT mode. 

FCl TRNG Menu 

FCl TRNG D, Trans Micro, RNG Low XTAL Current 
and Rng Gte Circs 


Name: 


FCl TRNG D 


Description: Continues trouble-shooting of FCl Track Range 

NoGo in both modes by checking the sigma 
video level tolerance. 


Called by: RNG NoGo Both Modes 

Calls: FCl TRNG C and FCl TRNG Sub D 


Name: 


FCl TRNG C 


Description: Continues trouble-shooting of FCl Track Range 

NoGo in both modes via gradient adjustments 
in PAT and PDT modes. 


Called by: FCl TRNG D 

Calls: None 
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Name: 

FCl TRNG Sub D 

Description: 

This procedure is common to FCl TRNG Sub D 
and Trans Micro. In either event, it 
continues trouble-shooting of FCl Track Range 
NoGo in both modes via checking the sigma LIN 
video. 

Called by: 

FCl TRNG Sub D and Trans Micro. 

Calls: 

FCl TRNG E 

Name: 

FCl TRNG E 

Description: 

Continues trouble-shooting of FCl Track Range 
NoGo in both modes via input checks at 
UD401/C-B/16. 

Called by: 

FCl TRNG Sub D 

Calls: 

None 

Name: 

Trans Micro 

Description: 

Continues trouble-shooting of FCl Track Range 
via a transmitter or microwave components 
check and/or replacement. 

Called by: 

RNG NoGo Both Modes 

Calls: 

FCl TRNG Sub D (described previously) 

Name: 

RNG Low XTAL Current 

Description: 

Allows trouble-shooting of FCl Track Range 
NoGo in both modes in the event that there is 
low crystal current. 

Called by: 

RNG NoGo Both Modes 

Calls: 

None 
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Name: 


Description: 

Called by: 
Calls: 


Rng Gte Circs 

Continues trouble-shooting of FCl Track Range 
NoGo in both modes via the range gate circuit 
tests. 

RNG NoGo Both Modes 
None 
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FCl TRNG Menu 
(Track Range) 



















I. FC2 PROCEDURES 


Name: 

FC2 Menu (Figure 9) 

Description: 

Allows selection of FC2 Designation, 
Acquisition and Track procedures. 

Called by: 

Performance Menu 

Calls: 

FC2 DTRB Menu, FC2 ACQ Menu, and FC2 TBER 

Menu. 

Name: 

FC2 DTRB Menu 

Description: 

Allows selection of FC2 Designation Time, 
Range and Bearing procedures. 

Called by: 

FC2 Menu 

Calls: 

FC2 DT Menu, FC2 DR and FC2 DB 

Name: 

FC2 ACQ Menu 

Description: 

Allows selection of FCl ACQ procedures. 

Called by: 

FC2 Menu 

Calls: 

FC2 ACQ Menu 

Name: 

FC2 TBER Menu 

Description: 

Allows selection of FC2 Track Bearing, 
Elevation and Range procedures. 

Called by: 

FC2 Menu 

Calls: 

FC2 TBE Menu and FC2 TR Menu 
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J. FC2 DESIGNATION TIME PROCEDURES 


Name: 

Description: 

Called by: 
Calls: 


FC2 DT Menu (Figure 10) 

Allows selection of one of three possible 
paths; Submenu, range counter LED check and 
range gate check. 

FC2 DTRB Menu 

FC2 DT Submenu, FC2 DT G and FC2 DT Case 4 


Name: 

FC2 DT Submenu 

Description: 

Allows selection of one of five possible 
paths; train velocity checks, no range gate 
movement, range gate movement slow, no track 
antenna movement, or track antenna movement 
is slow. 

Called by: 

FC2 DT Menu 

Calls: 

FC2 DT F, FC2 DT No Rng Gte Mvmt, FC2 DT Rng 
Gte Mvmt Slow, FC2 DT No Trk Ant Mvmt, and 

FC2 DT Trk Ant Mvmt Slow 

Name: 

FC2 DT F 

Description: 

Continues trouble-shooting for FC2 

Designation Time via a train velocity check. 

Called by: 

FC2 DT Submenu 

Calls: 

FC2 DT Fa and FC2 DT Fb 

Name: 

FC2 DT Fa 

Description: 

Continues trouble-shooting of FC2 Designation 
Time via a check on the Gyro temp low lamp. 

Called by: 

FC2 DT F 

Calls: 

FC2 DT Fc 
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Name: 

FC2 DT Fc 

Description: 

This procedure is common to the FC2 DT No Rng 
Gte Mvmt and FC2 DT No Trk Ant Mvmt. In 
either case, it continues trouble-shooting of 
FC2 Designation Time via a DC voltage check 
at UD417. 

Called by: 

FC2 DT Fa and FC2 DT B 

Calls: 

None 

Name: 

FC2 DT Fb 

Description: 

Continues trouble-shooting of FC2 Designation 
Time via a DC voltage level check at TP2. 

Called by: 

FC2 DT F 

Calls: 

None 

Name: 

FC2 DT No Rng Gte Mvmt 

Description: 

Allows trouble-shooting of FC2 Designation 
Time in the event that there in no movement 
in the range gate. 

Called by: 

FC2 DT Submenu 

Calls: 

None 

Name: 

FC2 DT Rng Gte Mvmt Slow 

Description: 

This procedure is common to FC2 DT Submenu 
and FC2 DT Case 4. In either case, it allows 
trouble-shooting of FC2 Designation Time in 
the event that the movement of the range 
gates are slow. 

Called by: 

FC2 DT Submenu and FC2 DT Case 4 

Calls: 

None 
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Name: 

FC2 DT No Trk Ant Mvmt 

Description: 

Allows trouble-shooting of FC2 Designation 
Time in the event that there is no track 
antenna movement. In addition, it allows the 
selection of one of five possible paths each 
performing a different type of system check. 

Called by: 

FC2 DT Submenu 

Calls: 

FC2 DT A, FC2 DT B, FC2 DT C, FC2 DT D and 

FC2 DT E 

Name: 

FC2 DT A 

Description: 

Continues trouble-shooting of FC2 Designation 
Time no track antenna movement via a check on 
the OPERATE lamp. 

Called by: 

FC2 DT No Trk Ant Mvmt 

Calls: 

FC2 DT Aa 

Name: 

FC2 DT B 

Description: 

Continues trouble-shooting of FC2 Designation 
Time no track antenna movement via a check of 
the antenna in bearing in simulate mode. 

Called by: 

FC2 DT No Trk Ant Mvmt 

Calls: 

FC2 DT Ba and FC2 DT Fc 

Name: 

FC2 DT C 

Description: 

Continues trouble-shooting of FC2 Designation 
Time no track antenna movement via a fuse 
check. 

Called by: 

FC2 DT No Trk Ant Mvmt 

Calls: 

None 
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Name: 


FC2 DT D 


Description: Continues trouble-shooting of FC2 Designation 

Time no track antenna movement via a train 
brake PD fuse check. 

Called by: FC2 DT No Trk Ant Mvmt 

Calls: None 

Name: FC2 DT E 

Description: Continues trouble-shooting of FC2 Designation 

Time no track antenna movement via a train 
FIELD lamp check. 

Called by: FC2 DT No Trk Ant Mvmt 

Calls: None 

Name: FC2 DT G 

Description: Continues trouble-shooting of FC2 Designation 

Time via a range counter LED check. 

Called by: FC2 DT Menu 

Calls: FC2 DT Ga 

Name: FC2 DT Ga 

Description: Continues trouble-shooting of FC2 Designation 

Time via a UD481/PanT LED check. 

Called by: FC2 DT G 

Calls: None 
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Name: 


FC2 DT Case 4 


Description: Continues trouble-shooting of FC2 Designation 

Time via system reset. 

Called by: FC2 DT Menu 

Calls: FC2 DT Rng Gte Slow (described previously) 
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F41, F42 



























K. PC2 DESIGNATION RANGE PROCEDURES 


Name: 

Description: 

Called by: 
Calls: 

Name: 

Description: 


Called by: 
Calls: 


FC2 DR A (Figure 11) 

Allows trouble-shooting of problems 

associated with FC2 Designation Range. 
FC2 DTRB Menu 
FC2 DR B 


FC2 DR B 

This procedure is common to and a continuance 
of both FCl designation range and FC2 
designation bearing trouble-shooting 
procedures. In this instance, it continues 
the trouble-shooting procedures for FC2 
Designation Range. 

FC2 DR A and FC2 DB 

None 
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L. FC2 DESIGNATION BEARING PROCEDURES 


Name: 

Description: 

Called by: 
Calls: 


Name: 

Description: 


Called by: 
Calls: 


FC2 DB (Figure 12) 

Allows trouble-shooting of the FCS 
designation bearing in FC2. 

FC2 DTRB Menu 

FC2 DR B 


FC2 DR B 

This procedure is common to and a continuance 
of both FCl designation range and FCl 
designation bearing trouble-shooting 
procedures. In this instance, it continues 
the trouble-shooting procedures for FCl 
Designation Bearing. 

FC2 DR A and FC2 DB 

None 
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M. FC2 ACQUISITION PROCEDURES 


Name: 

Description: 


Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 


FC2 ACQ Menu (Figure 13) 

Allows selection one of four possible 
trouble-shooting paths; antenna movement in 
WCC elevation mode, low crystal current 
readings, weak or no video to detection 
circuits and acquisition detection at 
threshold level. 

FC2 Menu 

FC2 ACQ A, FC2 ACQ E, FC2 ACQ Ed, and FC2 ACQ 
F 


FC2 ACQ A 

Continues trouble-shooting of FC2 Acquisition 
procedures in the event that there is no 
antenna movement in elevation in WCC (manual 
mode) . 

FC2 ACQ Menu 

FC2 ACQ Aa, FC2 ACQ Ac, and FC2 ACQ Ad 


FC2 ACQ Aa 

Continues trouble-shooting of FC2 Acquisition 
via a check on the Servo Failure lamp at UD 
421, 

FC2 ACQ A 
FC2 ACQ Ab 
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Name: 


FC2 ACQ Ab 


Description: Continues trouble-shooting of FC2 Acquisition 

via a check on the elevation brake PS fuse 
F20. 

Called by: FC2 ACQ Aa 

Calls: None 

Name: FC2 ACQ Ac 

Description: Continues trouble-shooting of FC2 Acquisition 

via a check of the presence of DC voltage at 
TP5 and TP6. 

Called by: FC2 ACQ A 

Calls: None 

Name: FC2 ACQ Ad 

Description: Continues trouble-shooting of FC2 Acquisition 

via a check of the presence of DC voltage at 
TP6 and TP7, 

Called by: FC2 ACQ A 

Calls: None 

Name: FC2 ACQ E 

Description: Continues trouble-shooting of FC2 Acquisition 

in the event that the crystal current is low. 

Called by: FC2 ACQ Menu 

Calls: FC2 ACQ B and FC2 ACQ Ed 
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Name: 

FC2 ACQ B 

Description: 

Continues trouble-shooting of FC2 Acquisition 
via a check on the track receiver LO sample. 

Called by: 

FC2 ACQ E 

Calls: 

FC2 ACQ Ba 

Name: 

FC2 ACQ Ba 

Description: 

Continues trouble-shooting of FC2 Acquisition 
via a check for reflector voltage. 

Called by: 

FC2 ACQ B 

Calls: 

None 

Name: 

FC2 ACQ Ed 

Description: 

This procedure, and its subordinates, are 
common to the FC2 ACQ Menu and FC2 ACQ E. In 
both cases, it continues trouble-shooting of 
FC2 Acquisition in the event that there is 
weak or no video to the detection circuits. 

Called by: 

FC2 ACQ E and FC2 ACQ Menu 

Calls: 

FC2 ACQ C 

Name: 

FC2 ACQ C 

Description: 

Continues trouble-shooting of FC2 Acquisition 
via a check for RF input at UD417/A9-U1. 

Called by: 

FC2 ACQ Ed 

Calls: 

None 


128 


Name: 

Description: 

Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 


FC2 ACQ F 

Continues trouble-shooting of FC2 Acquisition 
via a check of the acquisition detection 
threshold level. 

FC2 ACQ Menu 

FC2 TBE Case 2 Submenu 


FC2 TBE Case 2 Submenu 

Procedures utilized in the trouble-shooting 
of FC2 Track Bearing and Elevation are also 
used in order to continue trouble-shooting of 
FC2 Acquisition. 

FC2 ACQ F 

FC2 TBE Case 21 


FC2 TBE Case 21 

Procedures utilized in the trouble-shooting 
of FC2 Track Bearing and Elevation are also 
used in order to continue trouble-shooting of 
FC2 Acquisition. 

FC2 TBE Case 2 Submenu 

FC2 TBE Case 21 
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N. FC2 TRACK BEARING AND ELEVATION PROCEDURES 


Name: 


FC2 TBE Menu (Figure 14) 


Description: Allows selection of one of three possible 

track bearing and elevation paths; Nogo PDT 
mode, NoGo PAT mode or NoGo both modes. 


Called by: FC2 TBER Menu 

Calls: FC2 TBE NoGo PDT Mode, FC2 TBE NoGo PAT Mode 

and FC2 TBE NoGo Both Modes 


Name: 


FC2 TBE NoGo PDT Mode 


Description: Allows trouble-shooting of FC2 Track Bearing 

or Elevation in the event that there is a 
NoGo in PDT mode,. 


Called by: 


FC2 TBE Menu 


Calls: 


FC2 TBE C 


Name: FC2 TBE C 

Description: This procedure is coitraon to all of the three 

primary Menu selections in FC2 TBE Menu. In 
all cases it continues trouble-shooting 
procedures for the appropriate NoGo mode. 


Called by: FC2 TBE NoGo PDT Mode 

Calls: None 


Name: 

Description: 

Called by: 
Calls: 


FC2 TBE NoGo in PAT Mode 

Allows trouble-shooting of FC2 Track Bearing 
or Elevation in the event that there is a 
NoGo in PAT mode. 

FC2 TBE Menu 

FC2 TBE C (described above) 
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Name: 


FC2 TBE NoGo Both Modes 


Description: 

Called by: 
Calls: 


Name : 

Description: 

Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 


Allows trouble-shooting of FC2 Track Bearing 
and Elevation in the event that there is a 
NoGo in both PDT and PAT modes. It allows 
selection of one of three possible paths. 

FC2 TBE Menu 

FC2 TBE Trk Ant Oscillations, FC2 TBE Low 
XTAL Current and FC2 TBE F 


FC2 TBE Low XTAL Current 

Allows trouble-shooting of FC2 Track Bearing 
and Elevation NoGo in both PDT and PAT modes 
in the event that the crystal current is low 

FC2 TBE NoGo Both Modes 

FC2 TBE C (described previously) 


FC2 TBE Trk Ant Oscillations 

Allows trouble-shooting of FC2 Track Bearing 
and Elevation in the event that there are 
track antenna oscillations. 

FC2 TBE NoGo Both Modes 

FC2 TBE F 
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Name: 

Description: 

Called by: 
Calls: 

Name: 

Description: 

Called by: 
Calls: 


Name: 

Description: 


Called by: 
Calls: 


FC2 TBE F 

This procedure, and its associated sub- 
procedures, is a commonly used procedure in 
FC2 TBE NoGo both modes. It can be selected 
directly from the FC2 TBE NoGo Both Modes 
procedure or it can used to continue trouble¬ 
shooting of FC2 Track Bearing and Elevation 
track antenna oscillations by checking the 
video levels. 

FC2 TBE Trk Ant Oscillations and FC2 TBE NoGo 
Both Modes 

FC2 TBE D and FC2 TBE C (described above) 


FC2 TBE D 

Continues trouble-shooting of FC2 TBE F by 
checking the video levels. 

FC2 TBE F 

FC2 TBE Case 2 and FC2 TBE Case 3 


FC2 TBE Case 2 

This procedure is common in trouble-shooting 
track antenna oscillations or video level 
tolerance checks. In both cases, it is used 
to continues trouble-shooting of video levels 
in the event that the sigma video level is 
out of tolerance. 

FC2 TBE F and FC2 TBE D 

FC2 TBE Case Submenu 
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Name: 


FC2 TBE Submenu 


Description: Continues trouble-shooting procedures for a 

NoGo in both modes via a sigma video level 
checks. 


Called by: FC2 TBE Case 2 

Calls: FC2 TBE Case 21 


Name: 

Description: 

Called by: 
Calls: 


FC2 TBE Case 21 

Continues trouble-shooting of FC2 TBE Case 2 
via a IF Phase adjustment. 

FC2 TBE Case 2 Submenu 

FC2 TBE E 


Name: FC2 TBE Case 3 

Description: Continues trouble-shooting of video levels in 

the event that the sigma video level is in of 
tolerance, but the delta video levels are out 
of tolerance. 


Called by: FC2 TBE D 

Calls: FC2 TBE Case 31 


Name: 


FC2 TBE Case 31 


Description: 


Called by: 


Continues trouble-shooting of video levels 
via additional IF Phase adjustments. 

FC2 TBE Case 3 


Calls: None 
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FC2 TBE Case 31 
(Case Inputs OK). 



TBE Menu 




























0. FC2 TRACK RANGE PROCEDURES 


Name: 

Description: 

Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 


FC2 TRNG Menu (Figure 15) 

Allows trouble-shooting of FC2 Track Range 
procedures by allowing selection of one of 
three possible paths: NoGo in PAT mode, NoGo 
in PDT mode and NoGo in both PAT and PDT 
modes. 

FC2 TBER Menu 

FC2 TRNG NoGo PAT Mode Only, FC2 TRNG NoGo 
PDT Mode Only and FC2 TRNG NoGo in Both 
Modes. 


FC2 TRNG NoGo PAT Mode Only 

Allows trouble-shooting of FC2 Track Range in 
the event that there is a NoGo in PAT mode. 

FC2 TRNG Menu 

FC2 TRNG C 


FC2 TRNG C 

This procedure is common to all three of the 
NoGo modules of FC2 Track Range. In this 
instance, it continues trouble-shooting of a 
NoGo in PAT Mode via gradient adjustments. 

FC2 TRNG NoGo PAT Mode Only, FC2 TRNG NoGo 
PDT Mode Only and FC2 TRNG D 

None. 
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Name: 


FC2 TRNG NoGo PDT Mode Only 


Description: Allows trouble-shooting of FC2 Track Range in 

the event that there is a NoGo in PDT mode. 


Called by: 

Calls: 

FC2 TRNG Menu 

FC2 TRNG C (described above) 

Name: 

FC2 TRNG NoGo Both Modes 

Description: 

Allows trouble-shooting of FC2 Track Range in 
the event that there is a NoGo in PDT mode. 

In addition, it allows selection of one of 
four possible trouble-shooting paths. 

Called by: 

FC2 TRNG Menu 

Calls: 

FC2 TRNG Low XTAL Current, FC2 TRNG Gte 

Circs, FC2 TRNG Trans Micro and FC2 TRNG F 

Name: 

FC2 TRNG Low XTAL Current 

Description: 

Continues trouble-shooting of a NoGo in both 
modes in the event that there is low crystal 
current. 

Called by: 

FC2 TRNG NoGo Both Modes. 

Calls: 

None 

Name: 

FC2 TRNG Gte Circs 

Description: 

Continues trouble-shooting of a NoGo in both 
modes via range gate ser^^’o-jump tests. 

Called by: 

FC2 TRNG NoGo Both Modes. 

Calls: 

None 
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Name: 


FC2 TRNG Trans Micro 


Description: 

Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 

Name: 

Description: 

Called by: 
Calls: 


Continues trouble-shooting of a NoGo in both 
modes via a transmitter and/or microwave 
test. 

FC2 TRNG NoGo Both Modes 
FC2 TRNG F 


FCl TRNG F 

This procedure, and its associated sub¬ 
procedures can be called directly from the 
FC2 TRNG NoGo Both Modes procedure or called 
as a result of a check on the transmitter 
and/or microwave components. In either 
event, it continues trouble-shooting of a 
NoGo in both modes via a check of the video 
levels. 

FCl TRNG NoGo Both Modes and FC2 TRNG Trans 
Micro 

FCl TRNG C (described previously) and FC2 
TRNG D 


FC2 TRNG D 

Continues trouble shooting of a NoGo both 
modes via a recheck of the video levels. 

FC2 TRNG F 

FC2 TRNG Case 2 
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Name: 


FC2 TRNG Case 2 


Description; 

Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 


Continues trouble-shooting procedures of a 
NoGo in both modes via a sigma video level 
tolerance check. 

FC2 TRNG D 

FC2 TRNG Case 21 


FC2 TRNG Case 21 

Continues trouble-shooting procedures of a 
NoGo in both modes by checking sigma video 
level tolerance in conjunction with IF Phase 
adjustments. 

FC2 TRNG Case 2 

None 
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FC2 TRNG Cme 



Figure 15: FC2 Track Range Menu 
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FC2 TRNG Menu 
(Tradi Range). 






















P. FC4 AND FC5 PROCEDURES 


Name: 

Description: 

Called by: 
Calls: 


FC4 and 5 Menu (Figure 16) 

Allows selection of FC4 and FC5 trouble¬ 
shooting procedures for designation time, 
track bearing and track range. 

Performance Menu 

FC4and5 DT Menu, FC4and5 TR and FC4and5 TB 


Name: 

Description: 

Called by: 

Calls: 

FC4and5 DT Menu 

Allows selection of one of three possible 
designation time trouble-shooting procedures. 

FC4and5 Menu 

FC4and5 DT, FC4 DT Only and FC5 DT Only 

Name: 

FC4and5 DT 

Description: 

Continues trouble-shooting procedures for FC4 
and FC5 Designation Time in the event of a 
NoGo. 

Called by: 

FC4and5 DT Menu 

Calls: 

None 

Name: 

FC4 DT Only 

Description: 

Continues trouble-shooting procedures for FC4 
Designation Time in the event of a NoGo. 

Called by: 

FC4and5 DT Menu 

Calls: 

None 
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Name: 


FC5 DT Only 


Description: 

Called by: 
Calls: 

Name: 

Description: 

Called by: 
Calls: 


Name: 

Description: 

Called by: 
Calls: 


Continues trouble-shooting procedures for FC5 
Designation Time in the event of a NoGo. 

FC4and5 DT Menu 

None 


FC4and5 TR 

Continues trouble-shooting procedures for FC4 
and FC5 Track Range in the event of a NoGo. 

FC4and5 Menu 

None 


FC4and5 TB 

Continues trouble-shooting procedures for FC4 
and FC5 Track Bearing in the event of a NoGo. 

FC4and5 Menu 

None 
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